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Az integrált 
kommunikáció jövője 


gy nemzetközi webkonferen- 
cián Bill Gates felvázolta, hogy 
milyennek képzeli az integrált 
kommunikáció jövőjét. A Microsoft több- 
féle technológia alkalmazása révén 
igyekszik megvalósítani az integrált 
kommunikációt: minden termékébe 
beépíti a jelenlét-észlelési funkciót, úgy 
integrálja egymással a különböző kom- 
munikációs csatornákat (az e-mailt, a te- 
lefont, az azonnali üzenetet, az SMS-t, a 
videokonferenciát és a webkonferen- 
ciát), hogy problémamentesen lehes- 
sen váltani a különböző csatornák kö- 
zött, továbbá olyan intelligens szoftvert 
biztosít, amely a felhasználó elérhetősé- 
gének és egyéni beállításainak megfe- 
lelően képes kezelni a kommunikációt. 
Az új integrált kommunikációs megoldá- 
sok legfontosabb előnyei: 
Sokoldalú jelenlét-észlelés — A 
Microsoft szoftverekbe épített jelen- 
lét-észlelésnek köszönhetően az 
infómunkások ellenőrizhetik az 
egyes személyek elérhetőségét, 
mielőtt kommunikációt kezdemé- 
nyeznének velük. 
Egységes kezelőfelület — A valós 
idejű kommunikáció különböző csa- 
tornáinak (e-mail, telefon, azonnali 
üzenetek, SMS, videokonferencia 
és webkonferencia) egyesítése ré- 
vén az infómunkások mindig az 
adott helyzetben optimális kommu- 
nikációs módot választhatják, prob- 
lémamentesen válthatnak a külön- 
böző csatornák között, de akár egy- 
szerre is használhatják őket. 
Beépített intelligencia — A kommu- 
nikációs eszközökkel integrált szoft- 
verek automatikusan kezelni tudják 
a kommunikációs funkciókat, ismer- 
vén a felhasználók beállításait, fizi- 
kai helyét, szervezeti viszonyát és 
közös témáitt. A szoftveres intelligen- 
cia segítségével a felhasználók sa- 
ját környezetüktől és a hívó féltől 
függően szabályozni tudják, hogy 
hogyan irányítsa hozzájuk a rend- 
szer a bejövő üzeneteket. 
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A Microsoft Office Rendszer új valós 
idejű együttműködési termékei és szol- 
gáltatásai: Microsoft Office Commu- 
nicator 2005 (korábbi kódnevén 
, Istanbul") — új integrált kommunikációs 
alkalmazás, a Microsoft Office Live 
Communications Server 2005 legújabb 
ügyfélprogramja. A Communicator sok- 
oldalú jelenlét-észlelési funkciókat nyújt, 
egyetlen alkalmazásban kombinálja a 
valós idejű kommunikációs csatornákat, 
emellett módot ad a PC és a telefon in- 
tegrálására is 


Microsoft Office Live Communica- 
tions Server 2005 Service Pack 1 — 
a Microsoft valós idejű kommuniká- 
ciós platformjának frissítése. A szer- 
vizcsomag tartalmazza a Microsoft 
Office Communicator 2005 támo- 
gatását, tökéletesebb védelmet 
nyújt a ,spim" (kéretlen azonnali 
üzenetek - spam over IM) ellen, és a 
követelményeknek megfelelő kap- 
csolatteremtési lehetőségeket bizto- 
sít a Live Communications Servert 
használó vállalat, és az MSN, az 
AOL és a Yahoo! nyilvános azonna- 
li üzenet-hálózata között. A Live 
Communications Server vállalati 
szintű azonnali üzenet-kezelő és je- 
lenlét-észlelési szolgáltatást nyújt. 
Microsoft Office Live Meeting 
2005 - a Microsoft népszerű 
webkonferencia-szolgáltatásának 
jelentős továbbfejlesztése, amely- 
nek segítségével a felhasználók on- 
line értekezleteket tarthatnak, és fo- 
lyamatos együttműködést valósít- 
hatnak meg anélkül, hogy egyszer- 
re ugyanazon a helyen kellene len- 
niük. A legfontosabb fejlesztések 
közé tartozik az iparág első integrált 
konferenciahívás-vezérlője, amely 
az összes vezető audiokonferencia- 
szolgáltató számára biztosítja a 
Live Meeting összeköttetés Office 
alkalmazásokból való indítását, va- 
lamint a hét újabb nyelvi verzió elér- 
hetőségét. 
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ISA Server 2004 
Enterprise Edition 


HÁLÓZATI TERHELÉSELOSZTÁS 





A MicrosoftISA Server 2004 Enterprise 
Edition új megvilágításba helyezi a tűzfalainkon 
alkalmazott hálózati terheléselosztást (NLB). 
Ez a technológia nagy rendelkezésre állást 

és skálázhatóságot tesz lehetővé az akár 31 
tagúvá bővíthető kiszolgálófarmok számára. 
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Mi VÁRHATÓ? 

Jelen cikk írásakor már megérkezett a publi- 
kus VVindows Server 2003 SP1 RCE, túl 
vagyunk egy közel másfél éves tesztelési 
intervallumon és talán a cikk megjelenésekor már letölthető is lesz 
az új szervizcsomag végleges változata, amely az XRF SP2 
mintájára szintén több lesz, mint egy szimpla javításhalmaz. 


Active Directory hozzáférés 
. SET komponensek segítségével 


Az ADSI És A .NET 


A .NET Framework igen könnyen használható formában biztosítja a címtár 
elérését (nemcsak az Active Directoryét), listázhatjuk a kiválasztott 
objektumokat, tetszőleges objektumot hozhaturk létre, és lekérdezhetjük, 
módosíthatjuk tulajdonságaikat is. 


Kalandozás az Internet 
Explorer körül 


MIÉRT JÓ, ILLETVE MIÉRT LEHETNE MÉG JOBB? 


A kérdés talán költőinek hat, bár nem annak szántam. Úgy érzem, 
érdemes foglalkozni a Microsoft böngészőjével, hiszen egy 

sor olyan előnnyel rendelkezik, amelyeket nem szívesen áldozunk fel, 
csak azért, mert van pár olyan hiányossága, ami azért kezelhető. 
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ASP.NET 2.O(whidbey) 


Mi VÁRHATÓ A 2005. Évi ASP.NET-BEN? III. RÉsZ 





Életszagú teljesítményfokozás az ASP.NET Cache 
szolgáltatásaival 
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A LOCALSYSTEM EM KRB. AS REG áss 
Clint KRBAS-REP EJT ÉB 
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Haladva a kirakós játékban, ebben a cikk- 
ben 15 újabb szolgáltatás ismertetése kö- 
vetkezik, persze továbbra is kizárólag a 
Windows Server 2003 Standard verzió- KRB. AP. REO 
jának alapértelmezett telepítése során fel- 

kerülő szervizek közül. Már csak két rész Ga 
van hátra ahhoz, hogy a közel 100 alap- VS 
szolgáltatás mindegyikét megismerjük 
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Server 


Ami a hivatalos Microsoft 
tanfolyamokból kimaract... 


SHAREPOINT PORTAL SERVER 2003 - JOGOSULTSÁGOK 





Rovatunkban újra a , csinálj magad intranetet" témát járjuk körbe. A 
Windows SharePoint Services és a ShareFPoint Rortal Server 2003 jo- 
gosultságait futjuk át röviden, megnézzük milyen lehetőségeink vannak 
felhasználóink jogosultságainak kezelésére, meghatározására. Hogyan 
tudunk csoportokat kezelni és ezeket hozzáférési, műveleti jogokkal fel- 
ruházni? Mindez hogyan hat a csoportmunka-helyekre? 








DUDr VVatson 


NAPI FELADATOK AZ SOL SERVER 2000-REL 


Sok cikk jelent már meg SOL Server témakörben, de eddig csupán 
fejlesztői szemszögből vizsgáltuk az adatbáziskezelést. 

A többség számára ez a megközelítés 
teljesen haszontalan. Ok azok az adatbázis- 
rendszergazdák, akik egy módosíthatatlan 
késztermék üzemeltetéséértfelelősek, 
abból kell kihozniuk a maximális teljesít- 
ményt, azt kell karbantartaniuk stb. Nekik 
szól ez a cikk. 














ISÁAÁ Server 2( 04 
Enterprise Edition 


HÁLÓZATI TERHELÉSELOSZTÁS 


A Microsoft ISA Server 2004 Enterprise Edition új meg- 


világításba helyezi a tűzfalainkon alkalmazott hálózati terhe- 


léselosztást (NL B). Ez a technológia nagy rendelkezésre 


állást és skálázhatóságot tesz lehetővé az akár 31 tagúvá 


bővíthető kiszolgálófarmok számára. 


z NLB rendkívül jól használható minden olyan kiszol- 

gáló-alkalmazásban, amelynek működése nem függ 

az alkalmazást futtató kiszolgáló hálózati identitásá- 
tól. A Windows NLB-farmhoz kapcsolódó kliensek, és ugyan- 
így a szerverfarm tagjain futó alkalmazások sem szereznek tu- 
domást a normális hálózati kommunikáció során arról, hogy a 
kiszolgálófarm tagjaiként együttműködő számítógépek önálló 
identitással rendelkeznek. A terheléselosztó farm használata 
nem új keletű megoldás a tűzfalakkal foglalkozók számára, 
mondhatnánk, hogy ez már egy kicsit ,lerágott csont". Hogy 
miért nincs ez teljesen így, azt a Microsoft ISA Server 2004 En- 
terprise Edition-ban alkalmazott, teljesen újszerű megközeli- 
tés világítja meg számunkra. Az ISA új verziójában a tűzfal- 
szoftverrel integrált, a tűzfal által menedzselt NLB megoldást 
kapunk. 
Alapvetően kétféle lehetőség kínálkozik az NLB kialakítására: 

m Az egyik a hagyományos" módszer, amelyben az ISA 
tulajdonképpen nem is tud arról, hogy egy kiszolgáló- 
farm tagjaként működő Windows-on fut. Ebben az eset- 
ben az NLB-t a már unásig ismert felületen konfiguráljuk, 
nagy küzdelmet víva több hálózati kártyás megfejtések- 
kel. Ennek a megoldásnak határozott előnye, hogy füg- 
getlen az ISA verziójától (megcsinálhatjuk Standard Edi- 
tion-nel is), konfigurációjától. Hátránya viszont, hogy 
az ISA szabálykészletek szinkronizálása a farm tagjai kö- 
zött nincs megoldva. 

m Az új verzióban azonban új megoldás is van az NLB 
kialakítására, valamint a konfiguráció kezelésére is, más 
szóval az ISA 2004 integrált NLB támogatással rendelke- 
zik. Ez a megoldás nagymértékben egyszerűsíti a több 
kártyával rendelkező gépekből épülő kiszolgálófarm 
kialakításával járó bonyolult beállítások áttekintését, hát- 
ránya viszont, hogy csak az ISA Enterprise verziójával 
működőképes. 

A hálózati terheléselosztás lehetővé teszi a kiszolgálófarm 
összes tagja számára egy adott alhálózaton a fürt közös (Clus- 
ter IP) IP címére érkező forgalom feldolgozását. Minden egyes 
tagon az NLB meghajtó filterként funkcionál a hálózati csatoló 
illesztőprogramja és a TCP/IP réteg között. Az ISA 2004 is ezen 
a ponton illeszkedik a forgalomba lehetővé téve a töpbbhálóza- 


tos komplex környezetekben is a terheléselosztás használatát. 
Ha a megvalósításban az NLB-ISA integrált megoldást választ- 
juk, a terheléselosztást per-hálózat alapon szabályozhatjuk, 
azonban ebben az esetben hálózatonként nem használhatunk 
több hálózati csatolót. 


Kiszolgálófarm-tagok közti 

(Intra-Array) kommunikáció 

Ha ISA integrált NLB megoldást alkalmazunk, minden ISA szá- 
mítógépünkbe további egy hálózati kártyát kell szerelnünk, me- 
lyet a farm tagjai az egymás közti kommunikációra fogják hasz- 
nálni. Erősen javasolt ezeket a csatolókat szeparált hálózaton, 
dedikált aktív eszközön keresztül összekapcsolni; ez a megol- 
dás növeli a rendszer teljesítményét, valamint fokozza a bizton- 
ságot. A tagok közötti belső kommunikációt ezután az új inter- 
fész használatára kell állítani. 

Az NLB-integráció alapértelmezésben nincs engedélyezve 
a telepítés után. A funkció bekapcsolásának módszerére ké- 
sőbb még visszatérünk. Miután engedélyeztük az integrációt 
egy ISA tömbre, minden olyan tömb-szintű hálózatra külön- 
külön beállíthatjuk az NLB működését, amelyik fizikailag is kap- 
csolódik a tömb tagjaihoz. Semmiképpen ne engedélyezzük 
olyan hálózatokon, amelyekhez nem tartozik fizikai kapcsolat, 
mert az helytelen működéshez vezet. Az ajánlás ezzel kapcso- 
latban egyértelmű és egyszerű: ha bekapcsoljuk a terhelés- 
elosztást, tegyük azt meg minden fizikai kapcsolattal rendelke- 
ző hálózaton, kivéve a tömb tagjai által belső kommunikációra 
használt (cluster network) hálózatot. Az NLB bekapcsolása 
után minden hálózaton meg kell adnunk a kiszolgálófarm tag- 
jai által közösen használt Virtuális IP címet (cluster IP). Később 
részletezzük, hogyan is kell ezt csinálni. 

Az ISA csomagszűrő rétegébe épített analizáló-motor vizsgá- 
latot hajt végre a beérkező csomagokon, ezért az ISA együtt- 
működik az NLB-vel annak érdekében, hogy a bejövő és a ki- 
menő forgalom minden egyes kapcsolati szál (session) eseté- 
ben az ISA tömb ugyanazon elemén haladjon keresztül. Ez egy 
fontos része az integrációnak, mivel e nélkül nem lehetne ala- 
pos csomagvizsgálatot végrehajtani. 


Terheléselosztás és virtuális 
magánhálózatok 

Amikor egy távoli kliens VPN kapcsolatot kezdeményez egy ISA 
tömbbel, a tömb tagjai közül csak az egyik építi fel akapcsola- 
tot, és IP címet allokál a kliens számára. Ettől a ponttól kezdve 
a távoli kliens minden forgalma ezen a tagon keresztül halad. 
Ha VPN-t és NLB-t is használni szeretnénk egy ISA tömbön, fon- 
tos a tűzfal-házirend készítésénél odafigyelni néhány részletre. 
Az ilyen szituációkban nem alkalmazhatunk felhasználó-azono- 
sításon alapuló szabályokat a vándorló VPN klienseink számá- 
ra, egész pontosan olyat nem, amelyik egy felhasználó számá- 
ra engedélyez valamilyen forgalmat. Ennek az oka egyszerű: 
elképzelhető, hogy másik ISA szerver kezeli a VPN kapcsolatot 
a klienssel, mint amelyik a kliens kérésének kiszolgálását hajtja 
végre. Ebben az esetben, ha a kérés teljesítéséhez azonosítás- 
ra van szükség, a VPN felhasználó azonosítói nem továbbítód- 
nak és a kérés teljesítése megtagadásra kerül. Egy kivétel van 
ez alól, a HTTP protokollra vonatkozó szabályok csoportja, mi- 
vel a felhasználói azonosítás ott ebben az esetben is tökélete- 
sen működik (mert a web-proxy bezavar a képbe). 


Telephelyek közti kapcsolatok 

Ha az ISA tömbünkön engedélyeztük az NLB-t egy távoli 
telephely-kapcsolatban, a tömb egyik tagja automatikusan 
hozzárendelődik az adott VPN csatornához, ezért a telephe- 
lyek között nem alakulnak ki párhuzamos csatornák. Abban 
az esetben azonban, ha a csatornát üzemeltető tag kiesik 
a műszakból, a VPN csatorna automatikusan felépül egy má- 
sik tagon. 

Két tömb is összekapcsolható telephelyek közti VPN segítsé- 
gével, ebben az esetben azonban mindkét oldalon ismerni kell 
a túloldali dedikált IP címeket is. Az ISA szerver NLB- 
funkcionalitását használhatjuk a Windows Server 2003 NLB 
beállítások menedzselésére az ISA tömb tagjain. Az integrált 
NLB megoldás további előnye, hogy a kliensek (a virtuális 
IP-re érkező) kérése automatikusan továbbítódik a VPN-t üze- 
meltető ISA taghoz, valamint ennek hibája esetén a kapcsolat 
(és ezzel együtt a kliens forgalom is) automatikusan áttelepül 
egy másik működő gépre. Van azonban néhány megfontolan- 
dó kérdés az NLB és a telephelyek közti kapcsolatok kialakítá- 
sával kapcsolatban: 

m Több ISA-ból álló tömb esetén, ha NLB-t szeretnénk 
használni, muszáj az integrált megoldást választani, 
ellenkező esetben a telephelyek közti VPN nem fog mű- 
ködni. 

m Ha ISA Integrált NLB-t használunk (mást pedig, ugye, 
nem lehet) VPN környezetben, a külső interfészen (vagy 
azon, amelyik fogadja a VPN kapcsolatokat) kötelezően 
engedélyezni kell a terheléselosztást. Ugyanígy kell eljár- 
nunk minden olyan hálózat esetén, ahonnan vagy ahová 
a VPN kliensek forgalmát engedélyezni kívánjuk. 

m Ha több szerveres környezetben NLB-t engedélyezünk 
és telephelyek közti VPN-t is használunk, az ISA Configu- 
ration Storage Server (CSS) funkciót át kell helyezni egy 
olyan számítógépre, amelyik nem tagja semmilyen ISA 
tömbnek, vagy egyáltalán nem futtat ISA szolgáltatásokat 
(lehetőleg valamelyik védett hálózatba). Ha a CSS az ISA 
tömb valamelyik tagján lenne, és ez a tag történetesen 
nem lenne azonos a VPN csatornát üzemeltető géppel, 
a túloldali VPN kiszolgáló elvesztené a kapcsolatot a CSS 
tárolóval, mivel olyan helyen keresné, ahol nincs is. 


it 8 97 S EG tt EVE I 


o 
a 


Virtuális IP címek 

Amikor a terheléselosztást engedélyezzük, további IP címet 
kell hozzárendelnünk az adott hálózathoz. Amint ezt meg- 
tesszük, az ISA szerver önállóan automatikusan módosítja 
a hálózati objektum tulajdonságát, csakúgy, mint a TCP/IP 
beállításokat a Windows hálózati beállításokban. Minden há- 
lózati csatolón tehát, amelyen az NLB-t bekapcsoltuk, feltalál- 
ható két IP cím: egy az újonnan hozzárendelt , virtuális" IP cím 
és az eredeti , dedikált" IP cím is. ISA integrált NLB módban 
tehát minden csatolónak rendelkeznie kell egy saját dedikált 
címmel. A dedikált és a virtuális címnek ugyanabban az IP há- 
lózatban kell lennie, valamint az alhálózati maszkoknak is egy- 
formának kell lenniük. 


Egy csatoló több IP cím 

Néhány esetben olyan megoldásra lehet szükségünk, amikor 
az ISA farm egy hálózati kapcsolatához több IP címet kell ren- 
delnünk. Ilyen eset lehet például, ha a külső interfészen több 
szolgáltatást is meg szeretnénk hirdetni, de ezeket szolgáltatá- 
sonként különböző IP címen (pl.: egy mail- és egy webszerver 
külön IP-n). A több IP címmel rendelkező hálózati kapcsolato- 
kat az ISA integrált NLB megoldás nem tudja igazán kezelni. 
Maga az NLB ugyan kifogástalanul működik több címen is, 
azonban az ISA menedzsment felület nincs felkészítve az ilyen 
helyzetekre. Kétségbe esni nem kell, mindent pontosan úgy 
kell csinálni (integrált NLB módban), ahogy a szimpla -— egy IP 
címes - esetben is, majd amikor elkészültünk a beállításokkal, 
előkapjuk a Windows hálózati beállításokat, és amár meglévők 
mellé felvesszük a további szükséges címeket is. A lényeg: 
az összes további IP címet csak akkor szabad felvennünk, ha 
az ISA integrált NLB konfigurálással végeztünk. Ehhez hason- 
lóan kell eljárnunk visszafelé menet is, ha nem akarjuk felbori- 
tani a tömbünk konfiguráció-tárát, azaz, ha el szeretnénk távo- 
lítani az NLB-t egy hálózatról, először a pluszban hozzárendelt 
címeket kell leszednünk. Tehát jegyezzük meg, hogy a hálóza- 
ti kártyán elsőnek beállított IP cím automatikusan dedikált IP-vé, 
a többi virtuális IP-vé válik, de ezek közül csak az első (szum- 
mában a második) kerül automatikusan az ISA menedzsment 
konzolból a Windows hálózati beállításokba. 


Kétirányú affinitás 

Az ISA szerver NLB módban mindig automatikusan kétirányú 
affinitást állít be a kapcsolatok kezelésére. A legtöbb esetben 
a szimpla affinitás (ezt tudja ugye a Windows NLB alapból) nem 
hatékony megoldás. A legegyszerűbb példa erre, ha megné- 
zünk egy egyszerű szerverpublikálást: Egy belső védett háló- 
zatban működő szolgáltatást meghirdetünk a külső interfészen. 
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Ebben az esetben az NLB-t érdemes beállítani mind a külső — 
azinternet felé néző —, mind a belső - a szerver felé néző lábon 
beállítani. 

Mivel a meghirdetett szolgáltatást futtató szerverünk SecureNat 
kliens, alap értelmezett átjáróként a kiszolgálófarm belső, vir- 
tuális címét kell megadnunk. A helyes működéshez azonban 
szükséges, hogy a szerver válaszai mindig a kiszolgálófarm 
azon tagján keresztül jussanak el a klienshez, amelyen a kérés 
érkezett, mivel ez az egyetlen ISA szerver a farmban, amely 
tárolja az adott kapcsolati szálhoz tartozó állapot-, authentiká- 
ciós és egyéb információkat. Ennek a problémának a megol- 
dására vetjük be a kétirányú affinitást, melynek működését az 
1. ábra szemlélteti. 


Egyedi azonosítók 
a kiszolgálófarmban (Host ID) 
A telepítés során - előlünk rejtve — automatikusan generáló- 
dik minden ISA kiszolgálófarm-tag számára egy egyedi azo- 
nosító (2-től 32-ig), ez azonosítja az egyes gépeket a farmon 
belüli kommunikáció során. Ezt az értéket általában nem sza- 
bad megváltoztatnunk, bár előfordulhat olyan szituáció, ami- 
kor probléma lép fel, ilyen esetben az ISA szerver beleírja 
,bánatát" az eseménynaplóba, és megkér, hogy hárítsuk el 
a problémát. Az egyedi azonosítók átírása viszonylag egy- 
szerű feladat: 
m Az ISA menedzsment konzolban bontsuk ki a tömb ele- 
meit, menjünk a (Configuration 2. Servers) batyura 
m A jobboldali ablakban válasszuk ki a szerverünket, majd 
jobb klikk 2 Properties 
m A, Host ID" fülön válasszunk a listából egy még nem 
használt azonosítót 
Ne felejtsük el, hogy most hibaelhárítottunk, és az eredeti hiba 
miatt valószínűleg nem tudott elindulni a Microsoft Firewall Ser- 
vice, ezt ilyenkor manuálisan újra kell indítani. 





Az NLB leállítása/ elindítása 
Az integrált NLB módban az ISA szerver felelős azért, hogy 
megállapítsa, hogy a farm minden tagja aktív, működőképes 
és a forgalom megfelelően áthaladhat minden hálózat között. 
Ha az NLB egy szerver legalább egy hálózatán nem működik, 
az ISA kikapcsolja azt az adott szerver minden hálózatán. 
Ugyanígy az ISA találja ki azt is, ha a tag megfelelően működik 
és visszakapcsolódhat a farmhoz. A következő ellenőrzéseket 
hajtja végre a döntéshez: 

m A számítógép elérhető 
A ,Microsoft Firewall Service" fut 
Az NLB fut minden hálózati csatolón 
Minden hálózathoz hozzárendelhető egy fizikai csatoló 
Az NLB úgy van beállítva a gépen, hogy csak az ISA 
szolgáltatások után induljon. 


A terheléselosztás 
engedélyezése 
A továbbiakban tehát nézzük át az integrált NLB kialakításának 
egyes lépéseit. 
Az integrált terheléselosztás engedélyezéséhez a következő 
lépéseket kell végrehajtanunk: 
m AzISA menedzsment felületen bontsuk ki a tömb elemei 
batyut, válasszuk a (Configuration 2 Networks) helyet 
m A részletek ablakban válasszuk ki a , Networks" fület, 
ezen belül a megfelelő hálózatot. 





m A feladatpult részben kattintsunk a , Tasks" fülre, majd en- 
gedélyezzük az NLB-t az ,Enable Network Load Balan- 
cing Integration" varázsló elindításával 

m A, Virtual IP" részben adjuk meg a megfelelő IP címet (ez 
a kiszolgálófarm közös címe lesz az adott hálózaton) 

m A, Mask" részbe a megfelelő alhálózati maszkot írjuk (ez 
kötelezően ugyanaz, mint ami a szerver dedikált IP-jéhez 
tartozik) 

Apró kellemetlenség, hogy miután az összes hálózaton beállí- 
tottuk a terheléselosztást (kivéve természetesen a dedikált 
Cluster Network-öt) az ISA tömb összes tagját újra kell 
indítani. 

Ha el kívánjuk távolítani az Integrált NLB-t szervereinkről, ez 
az előzőekben ismertetett helyen hajtható végre. 

Először le kell tiltani az NLB-t az összes hálózaton, majd telje- 
sen el kell távolítani az ISA tömbről (Array 2 Configuration 2 
Networks 2 Tasks 2 Disable Network Load Balancing Integ- 
ration) 

Ha az ISA szerver szoftvert távolítjuk el a gépekről, az NLB 
beállítások nem törlődnek, és az NLBS meghajtó sem kerül el- 
távolításra a gépről. 


Az iintegrált terheléselosztás 
vezérlése 

Néhány fontos utasítást az ISA konzolról is kiadhatunk az NLB 
meghajtó számára, nem kell a parancssoros felületet használ- 
nunk. Sajnos nem minden NLB parancsot használhatunk, mert 
a feladatpult ide vonatkozó menüje csak akkor aktív, ha az NLB 
fut (tehát pl. elindítani nem tudjuk). A vezérlőparancs kiadásá- 
hoz menjünk el a (Monitoring 2 Services 2 NLB) batyuba, 
majd a feladatpulton a ,Tasks" fület bökve kiválaszthatjuk 
a ,Drain and Stop Selected Service" vagy a ,Stop Selected 
Service" parancsot. 


Kiszolgálófarm-tagok közti 

(Intra-Array) kommunikáció beállítása 

A telepítési procedúra során egy cím automatikusan kiválasz- 
tódik a belső kommunikáció számára, ez a cím általában a bel- 
ső hálózatba tartozó hálózati kártya címe. Ahogy az előzőek- 
ben is láthattuk, több szerveres környezetben a tagok közti 
kommunikációra dedikált adaptert használunk, ezért ezt 
a beállítást a telepítés után meg kell változtassuk. A lépések 
a következők: 

m Állítsuk be az új adapter IP címét a belső kommunikáció- 
hoz: (Configuration 2 Servers 2 Aktuálistag 2 Tasks 
2 Configure Selected Server 2 Communication 2 
Use this IP address for communication between array 
members) 

m Új hálózati objektum létrehozása: (Configuration 2 
Networks 2 Tasks 2 Create New Network) 

m Engedélyezzük a Web Proxy klienseket a hálózaton: 
(Configuration 2. Networks 2Cluster Net 2 Tasks 2 
Edit Selected Network 2 Web Proxy 2 Enable Web 
Proxy clients) 

m Tiltsuk le a Firewall klienseket a hálózaton: (Configura- 
tion 2 Networks 2 Cluster Net 2 Tasks 2 Edit Se- 
lected Network 2 Firewall client 2 Enable Firewall 
client support for this network) 
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Mi VÁRHATÓ? 


Jelen cikk írásakor már megérkezett a publikus VVindovws 


server 2003 SP 1 REZ), tül vagyunk egy közel másfél éves 


tesztelési intervallumon és talán a cikk megjelenésekor 


már letölthető is lesz az Új szervizcsomag végleges változa- 


ta, amely az XR SPE mintájára szintén több lesz, mint egy 


szimpla javításhalmaz. 


bben az évben számos újdonság kerül(het) be a 

Windows kiszolgálókat üzemeltetők látóterébe. Az itt 

[1] található vége-hossza nincs listában szó van sok 
új vagy megújított termékről, csomagról, kiegészítőről, de ki- 
szolgálói vonalon kiemelkedik belőle három nagyobb súlyú 
termék. Az egyik az - előreláthatólag - 2005 második felé- 
ben debütáló, jelenleg R2 [2] fantázianevű kiegészítés, 
amely nem javítócsomag, hanem valódi bővítmény, egy cso- 
kor ,Feature Pack", olyan szolgáltatásokkal mint az ADFS, 
ADAM, Windows SharePoint Services, az új DFS, vagy a 
Print Management Consol, stb. Sajnos a NAP (Network Ac- 
cess Protection [3]) és az új TS funkciók kikerültek belőle, 
de várhatóan így is teli leszünk izgalmas, új lehetőségekkel. 
Az év végén viszont eljön a Longhorn Server Beta1 ideje is 
(és a kliensé is), valószínűleg még több változással és új- 
donsággal, de erről még korai nyilatkozni. 
A harmadik fontos elem várható legkorábban, ez pedig a 
Windows Server 2003 első szervizcsomagja. A felsoroltak kö- 
zül valószínűleg ez a legszürkébb, de így is be tudok számol- 
ni jópár érdekes és hasznos változásról, újdonságról. Szeret- 
ném az elején leszögezni, hogy a cikk a publikus és a nem 
publikus bétaváltozatok használata során szerzett tapaszta- 
latokból származik, ám azt garantálni, hogy minden ugyanígy 
lesz a végső verzióban is, nyilván nem lehetséges. 


Egyszóval: a biztonság 

Ekörül forog még szinte minden, az SP1 legnagyobb szám- 
ban megjelenő újításai (és persze a szokásos integrált frissí- 
tések is) erről szólnak. Jelentős mennyiségű az XP SP2-ben 
már megismert restrikció került bele ebbe a szervizcsomag- 
bais, pl. a Windows Tűzfallal, az Internet Explorerrel (add-ons 
tiltás, ActiveX , BindToObject", information bar, pop-up blok- 
koló, zone elevation blocking, stb.) vagy a Outlook Express- 
szel kapcsolatban (pl. AES), de az RPC és DCOM szigorítá- 
sok, a DEP illetve a TCP/IP kapcsolatok terén is ugyanazok a 
szigorúbb elvek érvényesülnek, ám ezekről most nem lesz 
szó, viszont nézzünk egy felsorolást azokról az újdonságok- 
ról, amelyeket megemlítünk: 
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Telepítés utáni automatizmusok (Windows Firewall -- 
Post-Setup Security Updates) 

Állomány- és mappa hozzáférés változások (Access- 
based Directory Enumeration) 

Security Configuration Wizard 

Wireless Provisioning Services 

Ömlesztett újdonságok (Network Access Ouarantine 
Control, DCdiag, RIS, RsoP, stb.) 


A telepítés utáni automatizmusok 
apropóján 

Egy sommás megállapítással kezdeném: hogy egy szűzen 
(tűzfal/vírusirtó/antispyware nélkül) az internetre kötött Win- 
dows operációs rendszer mennyi ideig képes biztonságban 
működni, az vita tárgya szerteszét a világban, viszont a se- 
bezhetőség realitása nem az. Ezért fontos teendő volt, hogy 
a kliensek (XP SP2) után a kiszolgálók sebezhetősége is erő- 
teljesen javuljon egy ilyen szélsőséges szituációban. A 
megoldás két részből áll: egyrészt a Windows tűzfal automa- 
tikus és az indítási folyamat egész alacsony szintjén történő 
bekapcsolásából másrészt az ún. PSSU (Post-Setup Security 
Updates) technika alkalmazásából. 

A Windows tűzfalat jól ismerhetjük már az XP SP2-ből, ezzel 
kapcsolatban gyakorlatilag nem látszik változás. Az viszont, 
hogy mennyiben szolgálja a korai védelmet, rögtön kiderül, ha 
megnézzük, hogy hogyan és mikor indul el. Ugyanis korábban 
(akármilyen csúcs védelemmel rendelkeztünk) mindig létezett 
egy lyuk a hálózati szolgáltatások és az ICF vagy más tűzfal 
bekapcsolása között (kivéve pl. ISA 2004, amely bebújik a 
TCP/IP réteg alá és így már az indítás összes fázisában el tud- 
ja hessegetni az illetékteleneket). Ennek a holtidőnek a léte 
nem túl szerencsés, de muszáj volt, hiszen a tűzfal-alkalma- 
zásnak be kellett várnia a többi rendszerszolgáltatást a függő- 
ségi viszonyok miatt. Az SP1 telepítése után viszont rögtön 
életbe lép egy statikus szabály alapú állapotszűrés (ún. rend- 
szerindítási házirend), ami a DNS/DHCP protokollok mellett 
átengedi a csoportházirend érvényre jutásához szükséges 
forgalmat is, de semmi mást nem. Ez a házirend csak addig 
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él, amíg a Windows Tűzfal nem kezd el működni, és van még 
egy fontos tulajdonsága: nem lehetséges módosítani. 
A másik lényeges elem a kötelező felhívás az azonnali frissí- 
tésre, amely az üzemeltető első bejelentkezése alkalmával 
elindul. Ezzel egy időben a tűzfal az összes bejövő kapcso- 
latot ignorálja, mindaddig amíg be nem zárjuk ezt az ablakot, 
ergo biztonságos körülmények között letölthetjük és telepít- 
hetjük a frissítéseket, majd mehet minden tovább. Azonban 
van egy kivétel, pontosabban kettő: ha korábban a csoport- 
házirend segítségével kivételeket állítottunk be a tűzfallal kap- 
csolatban, vagy a telepítés során engedélyeztük a Remote 
Desktop-ot, akkor ezeket a kapcsolatokat a lezárás alatt is en- 
gedélyezi a rendszer. 
A PSSU nem érhető el átlagos módon pl. a Start menüből. 
Csak a Windows Server 2003 olyan teljes telepítésére vonat- 
kozik, amely szervizcsomagot tartalmaz (pl. az SP1-gyel in- 
tegrált verzió). Akkor sem jelenik meg a PSSU, ha a követke- 
ző operációs rendszerekről frissítünk: 

m Windows 2000-ről a Windows Server 2003 SP1-re 

m Windows Server 2003-ról Windows Server 2003 SP1-re 


Viszont ha egy Windows NT 4.0 rendszert frissítünk, akkor 
használható lesz ez a szolgáltatás. További tudnivaló: ha 
felügyelet nélküli telepítési szkripttel telepítjük Windows Ser- 
ver 2003 rendszert, vagy ha esetleg a csoportházirend segít- 
ségével engedélyezzük vagy tiltjuk a Windows Tűzfalat, ak- 
kor sem fog megjelenni az SP1 telepítése után. 
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Felhívás a frissítések telepítésére 


Az állomány- és mappa hozzáférés 
változások 

közül egyre már igen régóta szükség lett volna, sosem értet- 
tem miért is nincs meg ez a lehetőség a Windows kiszolgálók 
esetén. Hogy tisztuljon a kép, arról van szó, hogy a szerver 
megosztott mappáiban a felhasználó csak azt a tartalmat lát- 
ja, amelyhez legalább olvasási jogosultsága van. Nos, ez az 
ún. , Access-based Directory Enumeration" lényege, amely 
az SP1 telepítése után a rendelkezésünkre áll. Ez az új lehe- 
tőség a megosztott mappában található állományokra és 
mappákra igaz, sajnos pl. a tallózásnál a megosztás mappák 
továbbra is látszanak bárki számára. Persze, ha egy megosz- 
tott mappa egy másikban helyezkedik el, akkor érdekes hely- 
zet áll elő: a tallózott listában látszik, ám ha a preparált , szü- 
lő" megosztásba belemegyünk, akkor már nem. Alapértelme- 
zés szerint ez a funkció nem áll rendelkezésre, hanem ma- 
nuálisan kell bekapcsolnunk egyesével a megosztott map- 


pákon. Elviekben ez az opció a NetShareSetilnfo API [4] attri- 
bútuma (SHI1005 FLAGS ENFORCE NAMESPACE 
ACCESS), amely bekapcsolására egy (egyelőre nem publi- 
kus) parancssori program áll rendelkezésre, amely használa- 
ta nagyon egyszerű, meg kell nevezni az adott megosztást és 
0/1-gyel jelölni a ki-bekapcsolást. Az még egyelőre nem tisz- 
tán látható, hogy a végső változatban ezt az attribútumot 
kivezetik-e a GUI-ra vagy marad a parancssori eszköz, minden- 
esetre kipróbáltam és tanúsíthatom hogy remekül működik, 
azaz tényleg csak azt látja a felhasználónk, amihez jogais van. 


Valószínűleg a Security 

Configuration Wizard 

bizonyul a legnagyobb dobásnak ebben a szervizcsomag- 
ban. Az viszont biztos, hogy ez a legkomplexebb az újdonsá- 
gok közül. Emlékszünk az IISLockdown-ra az IIS5-nél? Igazá- 
ból a párhuzam kicsit esetleges, és csak a működési elv alap- 
ján húzható meg, azaz varázsló 5 sablonok 5 egyéb extra 
beállítások. Ám az SCW az egész kiszolgálóra vonatkozó biz- 
tonsági beállítások egyszerű beállításában segít, és valóban 
nagyon alapos. A varázsló egy bővíthető XML adatbázis 
alapján, a szerepkörök definiálása után állapítja meg, hogy 
a közel 60 féle kiszolgálói szerepkör közül (pl. Domain Cont- 
roller, DHCP Server, DNS Server, WINS Server, File Server, 
Web Server, Exchange Back-End Server, Exchange Front- 
End Server, SOL Server, stb.) melyikhez milyen szolgálta- 
tásoknak, portoknak és egyéb funkcionális elemeknek kell 
engedélyezve lenniük. 

Ezután, a létrehozott biztonsági szabályok mentén, letiltja a 
szolgáltatásokat, zárolja a portokat, módosítja a registry tar- 
talmát valamint behangolja a naplózási beállításokat. Persze, 
a nyitva hagyott portok is korlátozhatók meghatározott ható- 
körökre, illetve kiaknázva az IPSec lehetőségeit, megvédhe- 
tőek. Egy szó mint száz, az SCW minden olyan funkciót letilt, 
amelyre nincs szükség a kiszolgáló által betöltött szerephez. 
A varázslás az eszköz telepítésével kezdődik, a szokásos 
módon. Az indítása után rögtön négy lehetőségünk lesz, azaz 
készíthetünk egy új szabálycsomagot; belepiszkálhatunk egy 
létezőbe; alkalmazhatunk egy korábban elkészítettet; illetve 
visszaállíthatjuk a legutolsó állapotot. 


nfiguration Wizard 


Configuration Action 
You can create a new securty polky; edit or apply an existing security policy; or rollback the 
last appbed security pobcy. 








Ezután kiválaszthatjuk azt a szervert, amelyikkel dolgozni sze- 
retnénk. Természetesen ez lehet egy távoli szerver is, azzal a 
feltétellel, hogy szinten telepítve van rajta az SCW (mind a 
négy alapművelet lehetséges lesz távolból is). 
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Amit viszont nem tehetünk meg az, hogy a 32 bites kiszolgá- 
lóról egy 64 bitest konfigurálunk és fordítva. 

A következő lépésben jön a felmérés, majd a kapunk egy ter- 
metes leírást az Összes szerver szerepkör jellemzőiről, a szük- 
séges szolgáltatásokról és portokról, a kliens alkalmazások- 
ról, egyszóval ez az ún. biztonsági konfigurációs adatbázis 
(lásd előző ábra). 

Most kezdődik az igazi munka, első körben az SCW felajánl 
a vizsgálatok alapján egy szerepkör listát, amelyhez hozzáte- 
hetünk illetve elvehetünk attól függően, hogy milyen szerepet 
tölt be az adott szerver. Nyomban ezután jön a kiszolgáló 
kliens szerepeinek kiválasztása, ahogy az ábrán látszik is 
(ahogy az is, hogy a , View" alatt mindig kellemesen finomít- 
hatjuk a látnivalót). 





Security Configuration Wizard 


Select Administration and Other Options 
These administration and other options are used to enable services and open ports. 


Bew: [installed options gi 







T B [ninstalled options 
Fi jSelected options 
7 Remote Administration Options 










IT 1; ffddte-tier application server (COM/DTC) options 
7 [Domain controller (Active Directory) options 












[7 Íz. Browse master 

FT b Browser 

TT 1 Content indexing ! 

[7 b Distributed transactions over RPC s! 
I 


Learn more about administration options, 








Ezt követi az egyéb gyári szükséges szolgáltatások illetve 
szervizek kiválasztása, majd külső szoftverek által telepített 
szervizek felsorolása. Ezután kérhetjük a nem használt szer- 
vizek letiltását és végül az első kör végén egy áttekinthető lis- 
tában tekinthetjük meg az összegzést. 


o 


Confirm Service Changes 
Before continuing, confirm that the service changes resulting from your role and other feature 
seletions are correct. 



















Disabled Alerter 
Application Layer Gateway 5... Disabled Internet Connection St 
Distributed Link Tracking Cbent Manual Automatic Link tracking for users" 
1PSec Services Automatic Disabled Ipsec Services 
Microsoft POP3 Service Manual Automatic POP3 server, Exchange 
Network Provtsonng Sermee Manual Disabled Wireless Networking ar 
Portable Media Serial Number Manual Disabled Independent 

Print Spooler File and Print server fot 
Rfttote Aecess Auto Connec.., . Manual Disabled Independent sű 


AN tere eke eine ehengesy 90 PekIO RE ERRE Poss EL eleve He see eri een HiJe, 












Lea more about conérming service changes. 











A második kör a hálózati biztonsági beállításokra vonatkozik, 
a portokat tilthatjuk illetve hatókör vagy az IPSec segítségé- 
vel korlátozhatjuk az elérést. A harmadik körben a regisztrá- 
ciós adatbázis néhány kiemelt kulcsa segítségével további 
fontos korlátozásokat eszközölhetünk. Első opció az SMB 
aláírás kikényszerítése, amellyel a közismert , The man in the 
middle" típusú támadást lehet kiküszöbölni. Óvatosan bán- 
junk ezzel, mert a régi kliensek ezt a módszert nem ismerik, 
ezért már a tartományba belépés sem sikerülhet az AD kliens 
nélkül. A másik opcióval az összes állomány- és nyomtatási 
forgalom digitális aláírása váltható ki. 


Security Configuration Wizard [ 


Reguire SMB Security Siígnatures 
The following information determines whether Server Message Block (SMB) security signatures 
are enabled or regured. 








5. Windows NT 4.0 Service Pack 6a or later. 

"Windows 95 with the Directory Services Ckent Pack installed 

5. Windows 98 or Windows Milennium Edition 

5 Windowis CE ,NET 4.2 (for example Windows Mobile 2003 Second Edition) or later 


FF It has gurplus processor capacity that can be used to sign ie and print traffic 
This option digttaly signs all fe and print traffic, This signing is processor intensive, so ít ís 
recommended only f the server does not normally exceed 709 processor utization.. 


These settings affect the ReguireSecuritySignature value ín 
HKLMISystemtCurrentControlsetlServicesttanManServeriPari 


Learn more about 5MB security signatures. 











Ezután az LDAP signing (aláírás), azaz az LDAP forgalom tit- 
kosított és/vagy aláírt változatára térhetünk át (a kliensek a 
Windows 2000 SP3-tól ismerik) majd kiválaszthatjuk a LAN 
Manager hitelesítési eljárások számítógépekre alkalmazott 
változatai közül a megfelelőt (LM/NTLM/NTLMv2). 

Végül a negyedik körben következnek a naplózással kapcso- 
latos beállítások és készen is vagyunk. 
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Security Configuration Wizard 


Audit Policy Summary 
Before contiming, confirm that your auditing selectjons are correct. 





1F applied to the selected server, this security policy would use the following audting configuration: 


ET 





Success 


Directory Service Access Success Success 
Logon Events Success Success, falure 
Object Access Not aváted Success 

Polky Change Success Success 
Privilege Use Not audíted Not audted 
Process Tracking Not audíted Success 
System Events Success Success, falure 


[7 Also indude the SCWAudit inf security template. SCWAUdt.nf sets System Access Control Lists (SACL5) 
In order to audit access Of the fe system 


(A Once applied, these SCWAudit.iné SACLs cannot be removed using the SCW rolback action. 


Learn more about confeming auditing changes. 


A folyamat végén (ha van IIS, akkor lesz még egy az 
IISLockdown-hoz hasonló 5. kör is), a beállításokat elment- 
hetjük (.xml), egy másik gépen alkalmazhatjuk, beimportál- 
hatjuk, stb. 

A vezeték nélküli hálózatlétesítési szolgáltatás, azaz a Wire- 
less Provisioning Services az XP SP2-ben jelent meg először, 
ahol a WLAN kliens szoftver bővítményeként szerepel. A Win- 
dows Server 2003 SP1-ben pedig az Internet Authentication 
Service (1AS) szolgáltatást egészíti ki. Elsősorban hotspot 
szolgáltatóknak, WLAN hozzáférést nyújtó cégeknek készült, 
illetve nagyvállalati környezetben is használható, pl. vendég- 
hozzáférés biztosítása céljából (akár automatikusan egy erre 
a célra tartott VLAN-ra átirányítva). Röviden összefoglalva ez 
a szolgáltatás leegyszerűsíti a WLAN kliensek életét, hiszen 
a kapcsolódáskor az IAS (mint proxy) közvetítésével automa- 
tikusan tölthetik le a hálózat adatait, paramétereit a kiszolgá- 
lótól, így beavatkozás nélkül csatlakoznak illetve váltanak a 
szolgáltatók között (barangolás). Egyúttal az SP1-ben némi 
wireless biztonsági szint emelés is történt, hiszen a Windows 
Server 2003 immár támogatja a Protected Extensible Authen- 
tication Protocol-t (PEAP) és a WPA-t is. 

ale] 


Edit Profile 
Authentication  Accounting ] Attibute ] Advanced] 
Select the method of authentication for connection reguests that match the 
criteria specified in this policy. 
(7  Authenticate reguests on this server 


[v Protected EAP 
Állows clients to use wireless provisioning services, in addition to 
protecting credentials and authenticating the server. 





To complete set up of protected channel, configure Protected 
EAP in Remote Access Policy. 


C) Forward reges 
főrauthent 


JeNone configured -] 


C Accept users without authentication 


ts to the follgvéng remote RÉBIUS server group 














Ahhoz viszont, hogy az IAS-ban az előbbit az ábrán látható mó- 
don a grafikus felületen lássuk, némi registry módosításra van 
szükség. A következő helyen vegyük fel a ,EnableWPSCom- 
patibility" DWORD kulcsot 1-es értékkel és az IAS-ban és lőn. 


HKLMVSystemCurrentControlSetNServicestV 
RemoteAccessNPolicy 


A Microsoft egy nagyon alapos és hosszú dokumentumot 
máris kiadott az IAS illetve egyéb RADIUS szerverek valamint 
a WPS kapcsolatáról, amit innen [5] letölthetünk. 


Végül, de nem utolsósorban 
beszéljünk kisebb/nagyobb változásokról, fejlesztésekről, 
ömlesztve, ám nem súlyozva: 

mM 64 bit: az SP1 után a Windows Server 2003 a 64 bites 
hardverre is kiterjeszti a lehetőségeit 

m Network Access Guarantine Control: azaz a VPN karan- 
tén, amely a VPN-en bejövő kapcsolatok ellenőrzésére 
szolgál. Ha az általunk megszabott kapcsolódási felté- 
teleket (szervizcsomag, bekapcsolt tűzfal, aktuális fris- 
sítések, vírusirtó megkövetelése, stb.) a VPN kliens nem 
teljesíti, akkor a kapcsolódás megtagadása lesz az 
eredmény. A VPN karantén ISA 2004 esetén is létezik, 
és a Windows Server 2003 RTM-ben is működhet a Re- 
source Kit Tools-ból feltelepítve, most viszont bekerült 
az egyből telepíthető komponensek közé. További info 
a VPN karanténról itt [6], illetve letölthető példaszkrip- 
tek innen [7]. 

m Ugyanígy , járt" az RsoP (Resultant Set of Policy — Ere- 
dő házirend), azaz az eddig csak bővítményként meg- 
jelent eszközt beintegrálták. (Úgy néz ki, talán végre a 
GPMcC is belekerülhet az R2-be). 

Az SP1-es RIS támogatja a 64 bites image-eket. 
A Dcdiag.exe egy remek eszköz volt eddig is, ám most 
számtalan DNS szerver/zóna teszttel bővült: 


Dcdiag /test:DNS [/DnsBasic ] /DnsForwarders I] 
/DnsDelegation ] /DnsDynamicUpdate ] 
/DnsRecordRegistration ] /DnsResolveExtName 
[/DnsInternetName : InternetName] ] /DnsAl1l] 
[/f£f:Logfile)] [/ferr:Logerr] /S:DCName[/e)] [/v] 


Az ADPrep.exe okosabb lett, bizonyos Exchange és (a 

Windows 2000) AD sémaelemek konfliktusát megelőzi 

azzal, hogy nem hajlandó addig futni, amíg ki nem ja- 

vítjuk. A leendő , Changes to Functionality in Microsoft 

Windows Server 2003 Service Pack T" című dokumen- 

tumban, részletesen le lesz jegyezve, hogyan korrigál- 
junk (manuálisan) ebben az esetben. 

GÁL TAMÁS 

MCT, MCSE, MCSA, MVP 

gtamasatjszki.bu 
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[3] http:/ /tinyurl.com/ Saegj 
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[5] http:// tinyurl.com / 4utbp 
[6] http:/ / tinyurl.com/ eyna 
[7] http://tinyurl.com/7275e 


Actwve Directory hozzá- 
férés INET komponensek 


segítségével 


Az ADSLÉS A .NET 


A .NET Framework igen könnyen használható formában 


biztosítja a címtár elérését (nemcsak az Active 


Directoryétj), listázhatjuk a kiválasztott objektumokat, 


tetszőleges objektumot hozhatunk létre, 


és lekérdezhetjük, módosíthatjuk tulajdonságaikat is. 


Bevezetés 

Számos olyan eszköz létezik, amelyekkel hozzáférhetünk 
az Active Directoryban tárolt objektumokhoz, módosíthatjuk 
tulajdonságaikat, vagy akár a teljes tartalmat fájlokba expor- 
tálhatjuk. Vannak parancssori eszközök is, amelyek igen 
rugalmasan paraméterezhetők és szkriptekből, vagy időzítve 
is jól használhatók. 

Mégis egészen más , élmény" az, ha saját magunk írunk olyan 
programot, amely képes az AD írására és olvasására, mert 
ekkor gyakorlatilag MINDENT megtehetünk (persze csak 
a megfelelő jogosultságok birtokában), lehetőségeinknek 
csak a fantáziánk szabhat határt. Természetesen arra is lehe- 
tőségünk van, hogy programunk felhasználóit az AD hitelesít- 
se, és a megfelelő jogosultságok kiosztásához lekérdezhet- 
jük a hitelesített felhasználó csoporttagságát is. 

Az [1] címről letölthető mintaprogram bemutatja a .NET 
Framework címtárakkal kapcsolatos legfontosabb funkcióit, 
mintát ad a fent említett műveletek végrehajtására. A program 
konzol alapú, menüszerkezete a következő: 





LG C se dee e 


D:VXad.exe 





- Felhasználók, csoportok és számítógépek listája 
- Letiltott felhasználói fiókok listája 

- Új felhasználó 

- Új számítógépfiók 

- Felhasználó törlése 

- Számítógépfiók törlése 

- Felhasználó tulajdonságainak listája 

- Számítógép tulajdonságainak listája 

- Felhasználó autentikációja 

- Kilépés 


A mintaprogram menüszerkezete 


1 ma TECHNOLÓGIA 


o 
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Active Directory Service Interfaces, 
ADSI 

Az ADSI segítségével a különféle címtárakat egységes formá- 
ban kezelhetjük, mivel az általa biztosított csatolófelületek 
felhasználásával alkalmazásunk a különféle szerkezetű címtá- 
rakat is azonos módon érheti el. Az ADSI hasonló szerepet tölt 
be a címtárak elérésében, mint az ODBC a különféle adatbázis- 
kiszolgálók esetében. Segítségével a címtárakkal kapcsolatos 
gyakori feladatok - felhasználók kezelése, különféle erőforrások 
keresése - az elosztott, több címtármegoldást használó környe- 
zetekben is könnyen elvégezhetőek. Az ADSI objektumai való- 
jában COM objektumok, amelyek a kezelni kívánt címtár objek- 
tumait jelenítik meg, és COM csatolófelületeken keresztül érhe- 
tőek el. Az objektumok két csoportba sorolhatók; a konténer 
típusú objektumok más konténereket, és levél típusú objektumo- 
kat tartalmazhatnak. Az ADSI providerek valósítják meg a konk- 
rét címtártípus eléréséhez szükséges funkciókat. Amint az aláb- 
bi ábrán is látható, az ADSI-t használó ügyfeleknek (így a .NET 
Framework komponenseinek is) csak az ADSI provider által biz- 


ADSI provider Címtár 
Konténer 

komponens 
objektum 





COM 
/ objektum 











Fi 








Levél komponens 
objektum 














: NET komponensek 

















COM jet 
objektum 














Active Directory . A címtárszolgáltatás 
Services Interfaces saját protokollja 
(például LDAP) 


Címtár elérése ADSI provideren keresztül 


o 


mw 
o 
o 
u 
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tosított csatolófelület megfelelő használatával kell törődniük, 
a háttérben lévő címtár egyedi adottságainak megfelelő mű- 
veletek kezdeményezése már a provider feladata. 

Az ADSI által biztosított legfontosabb providerek a követ- 
kezők: 

m WinNT-// - a provider segítségével a Windows NT 4.0 
tartományokhoz férhetünk hozzá, és ez teszi lehetővé 
az önálló (Windows NT, 2000, XP) számítógépeken 
levő helyi címtár-adatbázisokhoz (SAM) való hozzáfé- 
rést is. Meg kell jegyeznünk, hogy a WinNT provider 
kompatibilitási okokból használható Active Directory 
esetében is, de ez számos korlátozással jár (a keresés 
nem támogatott, szervezeti egységek megadása nem 
lehetséges, stb.) ezért használata nem célszerű. 

m LDAP;// - ez a provider az LDAP protokoll segítségével 
elérhető címtárak (például az Active Directory) kezelé- 
sére szolgál, ezt használjuk a mintaprogramban is. 

m NDS;// - segítségével a Novell Directory Services szol- 
gáltatáshoz férhetünk hozzá. 


Minden ADSI objektum ügyfél oldali attridbútum-gyorsítótárral 
rendelkezik, amelyben ideiglenesen tárolódnak az objektum- 
hoz tartozó tulajdonságok nevei és értékei. A gyorsítótár jelen- 
tősen növeli az attribútumokkal végzett különféle műveletek tel- 
jesítményét, mivel nélküle programunknak minden egyes attri- 
bútum értékének beállítása után a címtárhoz kéne fordulnia. 


Az AD hozzáférést biztosító 

: NET komponensek 

A .NET Framework két komponenst biztosít a címtárak 
eléréshez, mindkettő a System.DirectoryServices névtérben 
található: 

A DirectoryEntry komponens a címtár egy meghatáro- 
zott levél, vagy tároló objektumának reprezentációja, létreho- 
zásakor meg kell adnunk a felhasználandó ADSI providert, 
és a megcélzott objektum azonosítóját a provider által meg- 
követelt szintaktika szerint. Az alábbi kódrészlet olyan 
DirectoryEntry objektumot hoz létre, amely a megadott nevű 
számítógép rendszergazda felhasználóját reprezentálja 
a WinNT;// provider segítségével: 


DirectoryEntry admin - new 

4 DirectoryEntry ( "WinNT: / /ezagep/ rendszergazda" ) ; 
Ha Active Directory tartomány felhasználóját megjelenítő ob- 
jektumot szeretnénk létrehozni, a kód a következők szerint 
módosul: 


DirectoryEntry admin - new 
4 DirectoryEntry ( "LDAP : //CN-rendszergazda , 
8 CN-Users ,DC-falatrax , DC-hu" ) ; 


Hasonló módon választhatjuk ki a címtár bármelyik levél- 
vagy konténerobjektumát, amelyet ezután a DirectoryEntry 
komponens tulajdonságainak és metódusainak segítségével 
érhetünk el. 

Már a konstruktorban megadhatjuk az objektum néhány 
további fontos tulajdonságát is. A második és harmadik para- 
méter a csatlakozáskor elküldendő felhasználónév és jelszó 
lehet, ha ezeket nem adjuk meg, a komponens automatikusan 
az aktuálisan bejelentkezett felhasználó adatait fogja használ- 
ni. Negyedik paraméterként az AÁLHENÜGAHOÁTYÁSS el enum 
értékei közül adhatjuk meg valamelyiket. A 0 s 








her komponens a címtárban való keresésre szolgál 
fesák LDAP providerrel használható). Létrehozásakor para- 
méterként kell adnunk egy DirectoryEntry objektumot, az így 
megadott konténer lesz a keresés kiindulópontja. Ha nem ad- 
juk meg ezt a paramétert, akkor alapértelmezés szerint a ke- 
resés az aktuális tartomány gyökerében indul. 


DirectoryEntry ADroot - new 

4 DirectoryEntry ("LDAP : //falatrax.hu") ; 
DirectorySearcher s - new 

$ DirectorySearcher(ADroot) ; 


A konstruktor további lehetséges paraméterei a következők 
(a kódrészletekben a tulajdonságokat az objektum létrehozá- 
sa után állítjuk be, de megadhatók a konstruktor paramétere- 
ként is): 
Filter - második paraméterként egy LDAP szintaktika szerin- 
ti szűrőfeltételt adhatunk meg (string), a keresés eredményé- 
ben csak a feltételnek megfelelő objektumok fognak szerepel- 
ni (alapértelmezés szerint minden objektum átjut a szűrőn): 
s.filter - , (objectCategoryzcomputer) " ; 
PFropertiesToL oad -harmadik paraméterként a keresés 
eredményobjektumaiba bekerülő tulajdonságok halmazát ad- 
hatjuk meg (String tömb). Alapértelmezés szerint minden tulaj- 
donság bekerül, ha csak meghatározott tulajdonságokat sze- 
retnénk visszakapni, az ,add" metódust kell meghívnunk: 


s.PropertiesToLoad.Ada( , Description" ) ; 
SezrchScope - utolsó paraméterként a keresés hatókörét 
állíthatjuk be, a SearchScope enum értékei közül valamelyikre: 

m Base - a keresés a kiindulópontként megadott objek- 
tumra (konténerre) korlátozódik. 

m OneLevel - csak a megadott kiindulópont alatt egy 
szinttel (a gyermekobjektumok között) keres, a kiindu- 
lópontban nem. 

m Subtree (alapértelmezés) - a kiindulópontban kezdődő 
teljes részfában keres (a kiindulópontban is). 


Ha Visual Studióban szeretnénk használni a komponenseket, 
akkor a megfelelő assembly referenciát (System.Directory 
Services.dlI) hozzá kell adnunk projektünkhöz. 


Add Reference JE 





office 7.0.3300.0 
1.0.3300.0 
stdole 7.0.3300.0 
System.Configuration.install.dil  1.0.3300.0 


C: WINDOWS Microsoft. NET V... sert 


C:(WINDOWSIMicrosoft.NETT, 
C:1Program FilesiMicrosoft.N... 
C:(WINDOWSIWMicrosoft.NETT,.... 
System.Data.dil 
System.Desgn.dll 


1.0.3300.0 
1.0.3300.0 


C: (WINDOWS Microsoft.NETT.. 
C: WINDOWS Microsoft. NET... 


System.dll 
System.Dravang.Design.dít 
System.Drawing.dil 

System EnterpniseServces 


1.0.3300.0 
1.0.3300.0 
1.0.3300.0 
1.0.3300.0 


C:(WINDOWSIMicrosoft.NETT.. a 
C:WINDOWSIMIcrosoft. NET... 
C-IWINDOWS Microsoft. NET... 
C:(WINDOWSIMicrosoft.NETV... 








System.Management 1.0.3300.0 —— C:IWINDOWSIMkrosoft.NETT... §] 
"selected Components: 
ezen ene I [de zt [docAuthor asz szterő] 
-NET C:IWINDOWSIMicrosoft.NETVFT..... 
(Hej BEsSEÍ[jezszal] 








Assembly referencia hozzáadása 


A következőkben megvizsgáljuk a komponensek segítségé- 
vel végrehajtható különféle alapfeladatok megvalósítását, 
a mintaprogram kódrészleteinek alapján. Természetesen a 
kódok ebben a formában nem használhatók , éles" program- 
ban, ehhez mindenkinek el kell végeznie a megfelelő módo- 
sításokat. 


Az AD tartalmának listázása 

Az alábbi kódrészlet kilistázza a teljes tartományból szárma- 
zó objektumokat a paraméterként megadott LDAP string 
szerinti szűrés után. Elsőként létrehozzuk a tartomány gyöke- 
rére mutató DirectoryEntry objektumot, majd a Directory 
Searcher konstruktorában ezt adjuk paraméterként. A szűrő 
beállítása után a DirectorySearcher objektum FindAll() metó- 
dusának meghívásával SearchResult objektumokból álló 
tömböt kapunk vissza, ennek elemein végiglépkedve lekér- 
jük a bennük lévő DirectoryEntry objektumokat, és kiírjuk ezek 
Path tulajdonságát. 


static void ListAD(string filter) ( 
string domainName - GetName(,Kérem a 
4 tartomány nevét: ,); 


4 
DirectoryEntry ADroot - new 
DirectoryEntry ( , LDAP: //" 4 domainName) ; 


DirectorySearcher search - new 


hl 
hd 
4, DirectorySearcher(ADroot) ; 


search.Filter - (filter); 
foreach(SearchResult res in search.FindAll()) ( 
Console .WriteLine(res . GetDirectoryEntrry ( ) . 
4 Path.ToString()); 
9 
3 


Már csak egyetlen dolog hiányzik a lista elkészítéséhez: meg 
kell határoznunk a kívánt elemeket leválogató LDAP szűrőt. 
A következő kódrészlet néhány egyszerű szűrőpéldát tar- 
talmaz: 


,, ( I robjectCategory-user) (objectCategory-group) ) " 


. (X(ObjectCategory-person) (objectClasszuser) 
4 (userAccountControl:1.2.840.113556.1.4.803:-2))" 


6 
(8-(objectCategoryz-user) ( ! telephoneNumber-—" ) ) 


Bonyolultabb lekérdezések összeállításához segítségül hív- 
hatjuk a Windows 2003 Server Active Directory Users and 
Computers eszközét; az elmentett lekérdezések (Saved 
Oueries) csomópontban grafikus felületen állíthatjuk össze 
az LDAP szűrőnket reprezentáló sztringet. 


2 
Name: 
fjetszó nem jár le 
Descriptiorc 
Duery root: 


ÉESZEEZEEN BE KATE ESő ú TSZESA 


[ Include subcontainers 





















(k(objectCategory-personj(objectClasszuser][userácc 
ountControk:1.2.840.113556.1.4.803:-65536)) 


Define 0uery... [ 


EI — ement I 





Felhasználók, akiknek jelszava soha nem fog 


lejárni 


Ha sok objektumot tartalmazó tartományban (vagy tartomá- 
nyokban) keresünk, érdemes lehet beállítani a SizeLimit 
és ServerTimeLimit tulajdonságokat is. A SizeLimit (int) tulaj- 
donság megadásával maximálhatjuk a keresés során vissza- 
adott objektumok számát. Ha a talált objektumok száma eléri 
a megadott értéket, a keresés megszakad, és visszaadja az 
addig összegyűjtött objektumokat. Erre vonatkozóan a kiszol- 
gáló is alkalmaz korlátozást (1000 objektum), így ennél na- 
gyobb érték megadásának nincs értelme. 

A ServerTimeLimit (TimeSpan) tulajdonság segítségével egy 
időintervallumot adhatunk meg; a kiszolgáló maximálisan 
ennyi időt fog a keresés végrehajtására fordítani. Itt is van 
a kiszolgáló által meghatározott érték (120 másodperc), 
ezt semmiképpen nem léphetjük túl. 


Az AD objektumok tulajdonságainak 
lekérése 

Az objektumok tulajdonságkészletét a címtár sémája határoz- 
za meg. Az attribútumok egy része több adat tárolására is ké- 
pes, és a sémától függ az is, hogy az egyes attribútumok 
milyen típusú adatokat tárolhatnak. 

Az alábbi kódrészlet segítségével egy megadott user objek- 
tum tulajdonságait listázhatjuk ki. Csak azok a tulajdonságok 
jelennek meg, amelyek beállított értékkel rendelkeznek, 
az üres tulajdonságok nem kerülnek be a listába. 

Első lépésként létre kell hoznunk az adott felhasználóhoz kap- 
csolódó DirectoryEntry objektumot. A kódrészlet természete- 
sen nemcsak a felhasználók, hanem bármilyen AD objektum 
tulajdonságainak  lekérdezésére képes, ehhez csak 
a DirectoryEntry konstruktorában megadott paramétert kell 
módosítanunk. A kódban látható domainNameToLDAP() 
függvény a felhasználótól bekért adatokat (tartománynév és 
a felhasználó neve) alakítja át a megfelelő LDAP sztringgé: 


, LDAP : //CN-rendszergazda , DC-falatrax , DC-hu" 


A programnak természetesen a tartomány DNS nevét (pél- 
dául falatrax.hu) kell megadnunk. 

A kiválasztott felhasználó (vagy más objektum) tulajdonságait 
a DirectoryEntry komponens Properties tulajdonsága által 
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visszaadott PropertyCollection gyűjtemény tartalmazza. 
Ennek Property Names tulajdonsága egy újabb kollekciót ad 
vissza, amelynek elemein végiglépkedve kiíratjuk az AD ob- 
jektum egyes tulajdonságának nevét. Mivel egyes tulajdon- 
ságok több értéket is tartalmaznak (gondoljunk csak például 
a felhasználó csoporttagságára), egy újabb iterációval kell ki- 
listáznunk az egyes nevekhez tartozó tulajdonságértékeket. 


static void ListUserProperties() ( 

string domainName - GetName ( , Kérem a 
tartomány nevét: ,); 

string userName - GetName(,Kérem a felhasználó 
nevét (Users konténer) : ,,); 


DirectoryEntry user - new 
DirectoryEntry (doma inNameTOLDAP ( domainName , 
s,Users" , userName) ) ; 


foreach(string propertyName in 
user .Properties .PropertyNames) ( 


int count - 
user .Properties (propertyNamel] . Count ; 
Console .WriteLine(propertyName 8 ,: ,); 


B et EGE Sz az ő EE 


for( int i -— 0; i c count; itt) 
Console .WriteLine (user. Properties 
4 (propertyNamel) [ii] . ToString( ) ) ; 


AD objektumaok létrehozása 

Minden AD objektum számos tulajdonsággal rendelkezik, 

hogy pontosan melyek ezek, azt az AD séma határozza meg. 

Ha új objektumot hozunk létre, természetesen bármely tulaj- 
2 


eat el dáá nai Mér 


Attibute Editor ] Security ] ] 


[7 Show mandatory attibutes 

[7 Show optional attributes 

TT Show only attributes that have values 
Attributes: 















accountExpires Large Integerélnte... 


accountNameHistory Unicode String Not Seb 
aCSPolicyName Unicode String cNot Seb 
adminCount Integer di 

adminDescription Unicode String cNot Seb 
adminDisplay Name Unicode String cNot Seb 
allovvedőttributes Object Identifier labeledURI:subSchen 
allowedáttibutesEffe... . Object Identifier msD$S-Cached-Membt 
allowedChildClasses Object Identiter NTFRSSubscriptionszt 
allowedChildülassesE... Object Identifier nTFRSSubsceriptionszt 
altSecurityidentities Unicode String cNot Seb 

assistant Distinguished Name . cNot Seb 
altibutelCertificateáttri.. .Octet Strina cNot Seb 






vál 





OK I Cancel I épp I 


Az ADSIEdit az AD séma alapján anem 
létező (nem beállított) tulajdonságokat is 
megmutatja 


donság értékét beállíthatjuk, de ehhez pontosan tudnunk kell 
a tulajdonság nevét. 

A legfontosabb tulajdonságok nevei az alábbi kódrészletben 
is szerepelnek, de az ADSIEdit program bármelyik tulajdon- 
ság nevét (sőt a beállítandó érték típusát is) megmondja 
nekünk. 

Az Active Directory nem tárolja az üres attribútumokat, az ob- 
jektumokban csak a valóban létező (beállított) tulajdonságok 
nevei és értékei jelenek meg, de az ADSIEdit a séma alapján 
a nem létező tulajdonságok neveit is megjeleníti. 

Az ADSIEdit programot a Windows 2003 CD MSUPPORTV 
TOOLS mappájában található mini Resource Kit részeként te- 
lepíthetjük fel. 

Az alábbi kódrészletben kiválasztjuk azt a konténert, amely 
az új objektumot tartalmazni fogja (DirectoryEntry létrehozá- 
sa), és annak Children kollekciójához hozzáadjuk a létreho- 
zandó objektumot. Az Add() metódus paramétereként az ob- 
jektum, és a létrehozásához felhasznált séma nevét (user, 
computer, stb.) kell megadnunk. 

Ezután következhetnek az új felhasználó tulajdonságai. Win- 
dows Server 2003 esetén egyetlen tulajdonságot sem kötele- 
ző megadnunk, hogy a felhasználó objektumot létrehozhas- 
suk; a samAccountName értéke is automatikusan generáló- 
dik bár az így létrejött objektum használhatósága erősen kér- 
déses. 

Ha mégis beállítanánk a tulajdonságokat, ismét a Properties 
kollekciót használhatjuk; az egyes tulajdonságok nevéhez 
tartozó Value értékét kell megadnunk a bekért adatoknak 
megfelelően. 

Képzeljük csak el, mennyit érhet egy jól megírt program, ha 
mondjuk egy szövegfájlban kapott lista alapján, másnap reg- 
gelig 1000 új felhasználót kell létrehoznunk, külön home map- 
pával és a felhasználónévből képzett induló jelszóval. 


static void AddUser() ( 

string domainName - GetName ( , Kérem a tartomány 
4 nevét: ,); 

string userName - GetName ( , Kérem az új 
4 felhasználó nevét (Users konténer) : ,); 

string pwd - GetName(, Jelszó: ,,); 


DirectoryEntry ADroot - new 
$  DirectoryEntry (doma inNameTOoLDAP (domainName , 
6. será jég JJ, 


DirectoryEntry newUser- 
4 ADroot.Children.Add(,CN-"-userName , "user" ) ; 


newUser.Properties[, name" ] . Value - userName ; 
newUser .Properties [ , samAccountName" ] . Value 
$ userName; 
newUser . Properties ( , uwserPrincipalName" ] . Value - 
$ userName rt ,e" -domainName; 
newUser.Properties[, Description"] . Value — , .NET 
4 progam által létrehozott felhasználó" ; 


newUser .Properties( , userAccountControl"] . Value — 
Gw 66048; 
newUser . ComnitChanges ( ) ; 


newUser . Invoke ( , SetPassword" , new 
$ object[](pwd)) ; 


Console.WriteLine(,Az új felhasználó (, t 
4 newUser.Properties[,distinguishedName" ]) . Value 
b ,) létrejött."); 
J 


A létrehozott objektum, és a tulajdonságok változásai nem 
íródnak azonnal fizikailag az AD-ba, a megadott értékek alap- 
értelmezés szerint előbb a helyi gyorsítótárba kerülnek. 
A gyorsítótár használatát a DirectoryEntry objektum Use- 
PropertyCache tulajdonságának beállításával szabályozhat- 
juk (alapértelmezés szerint van gyorsítótárazás). Miután min- 
dent beállítottunk, a gyorsítótár tartalma a Commit 
Changes() metódus meghívásával kerül be az AD-ba. 

A jelszó tulajdonság különleges elbánásban részesül, értékét 
nemlehet csak úgy megváltoztatni, és persze egyáltalán nem 
lehet kiolvasni. Hogy a jelszót beállíthassuk, az AD natív Set- 
Password metódusát kell meghívnunk, a DirectoryEntry 
Invoke() metódusának segítségével. 

A metódus csak akkor hívható, ha az új objektum már fizikai- 
lag is létezik, ezért a jelszó beállítása előtt meg kell hívnunk 
a CommitChanges() metódust. 


AD objektumok törlése 

Az objektumok törlését úgy végezhetjük el, hogy létrehozunk 
egy DirectoryEntry-t, amely a megfelelő konténerre mutat, és 
meghívjuk a hozzá tartozó Children kollekció Remove() me- 
tódusát. A metódus paraméterként a törlendő elemre mutató 
DirectoryEntry objektumot vár. 

Az alábbi kódrészletben bekérjük a tartomány és a törlendő 
számítógép nevét, létrehozzuk a , Computers" konténernek, 
és a törlendő számítógépfióknak megfelelő DirectoryEntry 
objektumokat, majd aRRemove() metódus meghívásával töröl- 
jük a fiókot. 


static void DeleteComputer() ( 

Console .WriteLine ( , Számítógép törlése:m"); 

string domainName - GetName (Kérem a tartomány 
b nevét: ,); 

string computerName - GetName (,Kérem a törlendő 
4 számítógépfiók nevét (Computers konténer) : ,,); 


DirectoryEntry ADroot - new 
$, DirectoryEntry (doma inNameTOoLDAP ( doma inName , 
4 ,Computers", ,")); 


DirectoryEntry computerToRemove - new 
4 DirectoryEntry(domainNameTOLDAP (doma inName , 
4 ,Computers", computerName) ) ; 


ADroot. Children. Remove (computerToRemove ) ; 
Console.WriteLine(,A ", t computerName 8 ,," 
4 számítógépfiók törölve."): 


Felhasználó autentikációja 

az AD adatai alapján 

Természetesen egyszerűen megoldható az is, hogy alkalma- 
zásunk felhasználóit az AD autentikálja. Az alábbi kódrészlet- 
ben bekérjük a tartomány nevét és a felhasználói fiók adatait, 
majd ezek felhasználásával létrehozunk egy DirectoryEntry 
objektumot. 

A natív ADSI objektumhoz való csatlakozással kikényszerítjük 
a hitelesítést. Ha ebben a sorban nem keletkezik hiba, 
a megadott adatok jók voltak, a felhasználó jogosult a belé- 
pésre (az esetleges hibát egy szinttel feljebb kapjuk el). 

Ha a már megismert módon lekérdezzük a felhasználó cso- 
porttagságát is, ennek megfelelően engedélyezhetjük, vagy 
tilthatjuk a programunk egyes funkcióihoz való hozzáférést. 


static void AuthenticateUset( ) ( 

string domainName - GetName ( ,Kérem a tartomány 
4 nevét: ,); 

string userName - GetName ( , Kérem a 
4 felhasználónevet: ,); 

string pwd - GetName(, Jelszó: ,,); 

string domainAndUsername - domainName t BSWV" 4 
4 userName; 
DirectoryEntry user - new 
DirectoryEntry ( , LDAP : / / "4domainName , 
domainAndUsername , pwd) ; 


§€ € 


Object obj - user.NativeObject; 


Console.WriteLine(,A felhasználó azonosítása 
$ sikeres!"); 


- 


SZERÉNYI LÁSZLÓ 


szerenyi lamet.bu 





A cikkben szereplő URL-ek: 


http:/ / store.netacademia.net/mshu/OTHER/technet. code/ 
AD-zip 











Kalandozás az Internet 
Explorer körül 


MIÉRT jÓ, ILLETVE MIÉRT LEHETNE MÉG JOBB? 


Akérdés talán költőinek hat, bár nem annak szántam. 


Úgy érzem, érdemes foglalkozni a Microsoft böngészőjé- 


vel, hiszen egy sor olyan előnnyel rendelkezik, amelyeket 


nem szívesen áldozunk fel, csak azért, mert van pár olyan 


hiányossága, ami azért kezelhető. 


indenekelőtt szeretném leszögezni, hogy cik- 

kemnek nem célja a browser-háborút erősíteni. A 

személyes tapasztalatok alapján meghozott vá- 
lasztás joga minden felhasználót megillet, abba nem szabad 
beleavatkozni! Írásomban én az Explorer azon előnyeit sze- 
retném megmutatni, amelyek miatt úgy gondolom, hogy to- 
vábbra is ez a böngésző a legjobb egy adott tartományi kör- 
nyezetben. 


Tények 

Való igaz, hogy kezelőfelületüket tekintve a konkurens böngé- 
szők fejlesztése kicsit elszaladt az IE mellett, talán a bizton- 
ságtechnikai fejlesztések úgyszintén. 
De szerintem még mindig egyértel- 
műen az Internet Explorer a leghatéko- 
nyabban használható, integrálható, 
szabályozható böngésző egy Windows 
szerverekből felépülő tartományban. 
Sokak örömére már hallható volt némi 
információ a következő generációs 
Internet Explorer 7-es fejlesztéséről és 
mihamarabbi kiadásáról. Mondhatjuk, 
hogy tán kicsit többet késett ez a beje- 
lentés, mint kellett volna, de előfordult 
már ilyen a Microsoft történetében. Ám a hasonló esetek vé- 
gén legtöbbször egy nagyon korrekt terméket vehettünk bir- 
tokba, ami bőven kárpótolt az elvesztett időért. Az időközben 


visszaszerzése miatt pedig aggódjanak a marketingszakem- 
berek, mi, rendszergazdák, amúgy sem unatkozunk. 


Miért szeretjük 
az IE-t jobban? 
Erre a kérdésre egy kis listával válaszolnék, aminek a pontjait 
a továbbiakban részletesebben is kifejtem. 
m Beépített NTLM és Kerberos támogatás 
m GPO-val szabályozható, amihez jókora gyári GPO 
készlet áll rendelkezésre 
m WindowsUpdate site elérése, használata. 
m Beágyazott VBS scriptek futtatása 








Az Internet Explorer 


tartományi környe- 
zetben vitathatatlan 


előnyökkel bír. ! 


Microsoft 


AAA Internet 


" Explorer 


A többi kiegészítő Explorer képességre most nem térnék ki, 
mert ezek nem is ugyanabban a súlycsoportban vannak, 
mint a lista elemei, illetve más böngészők is kisebb-nagyobb 
eltérésekkel ugyan, de eléggé hasonló kiegészítő funkciókat 
hoznak egymáshoz képest. A felsoro- 
lást tekintve pedig nekem már ennyi is 
elég volt ahhoz, hogy úgy döntsek, ná- 
lunk ez marad a hivatalos böngésző a 
hálózatban. 


NTLM 
Első pontként a , Windows NT LAN Ma- 
nager" hálózati autentikációs protokoll 
, . és a Kerberos alapú felhasználó-azo- 
! nosítás beépített támogatása szerepel. 
Ennek tartományi környezetben érez- 
hető előnyeiről nem kell sokat mesélni. Tegyünk fel egy 
egészen egyszerű esetet, amikor is az intranet információit 
egy belső SharePoint Portal Server biztosítja. Egyetlen 
központi adatbázisban, az Active Directory-ban tárolható az 
összes jogosultság, hozzáférés-szabályozás, így nem kell 
a felhasználónak minduntalan jelszóablakokkal megküzde- 
nie, amikor valamihez hozzá szeretne férni az intraneten. Jó 
esetben egyetlen egyszer adja meg az azonosítóját és 
jelszavát, amikor belép a tartományba. Onnantól, ha bár- 
milyen webes elérésre van szüksége a tartományon belüli 
IIS szervereken szolgáltatott adatokhoz, nem szükséges új- 
bóli azonosítást végeznie, mert az Explorer képes kezelni- 
átadni a szükséges információkat (ideértve a helyi tanúsít- 
ványokatis). Ez a mindennapos munkát nagyon megkönnyíi- 
ti, és központilag is egyszerűbb szabályozni: Mindent egy 

helyen! 


mv 
o 
o 


GPO-val szabályozható 
Vigyük tovább az előző példát, és mondjuk azt, hogy szeret- 
nénk az Explorer beállításait központilag szabályozni. Azaz le- 
gyen automatikus a Proxy beállítás, és az Intranet site-hoz is 
kapcsolódjanak a rendszergazda által megálmodott 
biztonsági szintek. Ezenkívül szeretnénk azt is, hogy minden 
felhasználónak megjelenjen a Favorites/Kedvencek folderben 
egy új könyvár, a cégen belül használatos linkekkel (mondjuk 
éppen az intranetet szolgáltató SharePoint szerver egyik por- 
táljának útvonalával). Ezen kívül még azt is szeretnénk, hogy 
a felhasználók ne tudják elállítani a központilag meghatározott 
jellemzőket. A feladatok megoldására számos GPO áll a ren- 
delkezésünkre, és még egy nagy halom megoldás a további 
szabályozási, testreszabási igények kielégítésére. Minden 
rendszergazda megtalálja a neki tetszőt. Itt azért fontos 
megemlíteni, hogy szükség lehet teljesen egyedi elképzelé- 
sek alapján kitalált beállításokra is. Példaként említeném a 
Temporary Internet Files folder méretének központi korlátozá- 
sát. Erre egyelőre nincs központi házirend, de remélem, hogy 
a következő frissítések alkalmával majd ez is belekerül az Exp- 
lorert vezérlő GPO-k népes táborába. 
Ha valaki elmélyül az említett Policy ob- 


sen hiányzik az összes többi böngészőből. Persze nem ez 
a helyzet a JAVA-val, ami pont az ellenkezőjéről híres, hiszen 
már szinte az otthoni kenyérpirítóhoz is lehet JAVA plugint le- 
tölteni. Ám igencsak sarkalatos pont lehet a VBS kérdés, ami- 
kor egy már meglevő, a cégen belül kifejlesztett alkalmazást 
használunk webes felületen. Ilyen esetben nem kérdés, hogy- 
ha , ehető tojásra" van szükségünk, nem a tojásokat kezdjük 
el patch-ekkel, update-ekkel bombázni, hanem olyan , tyúkot" 
szerzünk, ami megfelelő tojást rak. Persze előfordulhat, hogy 
a kis fiatal csirke még nem felel meg minden aktuális bizton- 
sági követelménynek. Van megoldás: zárjuk ketrecbe! A 
szakma jobbjai nem győzik hangsúlyozni, hogy nem akkor ér 
véget a telepítés, amikor a ,kék csík a végére ér", hanem ép- 
pen akkor kezdődik! Egy kis odafigyeléssel nagyon sok prob- 
léma orvosolható! 


Biztonság 

Amikor a biztonság szót leírjuk a számítástechnikával kap- 
csolatban, egy igen bonyolult, buktatókkal bőven ellátott te- 
rületre érkezünk. Rengeteg megközelítése van az informati- 
kában használatos biztonsági megol- 
dásoknak, ahol egy-egy apróságon 


jektumokban, láthatja, hogy szinte min- Elengedhetetlen, szinte az egész rendszer áll vagy bukik. 
dent lehet szabályozni, ami fontos lehet. Az elvárások pedig, hogy mondjuk a 
Egy nagyvállalati környezetben pedig hogy legyen böngésző telepítése után (,kék csík 


éppen ez a lényeg: a központi szabályo- 
zás. Ettől akár használhatnak a kliensek 
bármilyen más böngészőt is, egyedi 
beállításokkal. A lényeg, hogy mindig 
van egy, ami pont olyan, amilyet a fej- 
lesztőkkel közösen megálmodtak a 
rendszergazdák. Ha valami hiba adódik 
és az egyedileg használt böngésző nem 
birkózik meg a feladattal, máris érkezik 
a segítség: ,indítsd el az Explorert, és a kedvencek között 
megtalálod a linket, ami biztosan működni is fog". Egy olyan 
helyen, ahol a fejlesztőcsapat egy sor céges alkalmazást ké- 
szít, ami webes felületen érhető csak el, elengedhetetlen, 
hogy legyen a cég hálózatára nézve globális böngészőbeál- 
lítási lehetőség. Mégiscsak jobb, mintha a rendszergazdának 
egyenként kell ellátogatnia 300 géphez. bár így folyamatos 
személyes kontaktus lenne a kedves felhasználókkal, csak 
kétlem, hogy erre egy rendszergazda ráérne. 


WindowsWUpdate site elérése, haszná- 
lata 

Ez a pont végül is csak azért került bele a listába, mert az 
elengedhetetlenül fontos frissítések manuális elérése csakis 
az Internet Explorer-en keresztül valósulhat meg. , Természe- 
tesen" van SUS szerver a tartományban, ami feleslegessé te- 
szi a manuális frissítést, de mégis, ez olyan fontos képesség, 
ami miatt muszáj említést tenni róla. Egy új meghajtóprogram- 
ra van esetleg szükség, vagy csak szeretnénk megtudni, 
hogy van-e újabb kiadású driver a frissen vásárolt videokár- 
tyánkhoz? Ezt a SUS jelenlegi verziója nem tudja orvosolni, de 
mi magunk, az Internet Explorerrel és a Windows Update 
webhellyel igen. 


Beágyazott VBS scriptek futtatása 
Mivel a VBS nem egy nyílt szabványú környezet, ezért 
a HTML-be ágyazott Visual Basic Script-ek támogatása telje- 


a cég teljes hálózatára 
szóló böngésző- 


beállítási lehetőség. 


10099-nál") azonnal minden tökéletesen 
működjön, 

és már rögtön teljesen biztonságos és 
behangolt is legyen, nos, ezek a gya- 
korlatban igencsak ütik egymást. Néz- 
zük meg, hogy milyen is a biztonságos 
internetböngészés. Ugye ismerős az a 
felhasználói igény, hogy a számtalan 
weboldal, ezerféle megjelenítési techni- 
kája, mind-mind tökéletesen élvezhető legyen, de azért ne 
jusson be egyetlen kémprogram (spyware) se, és a vírusfer- 
tőzés is kizárt legyen? Ezt a feladatot nem bízhatjuk csak a 
böngészőre! Illetve ha mégis bekövetkezik a , fertőzés", nem 
tehetjük kizárólag csak a böngészőt felelőssé érte! Manap- 
ság elmondható, hogy akkor áll egy operációs rendszer 
legalább , három lábon", ha van hozzá víruskereső, kémpro- 
gram irtó és egy jó tűzfal. Plusz megoldott az aktuális bizton- 
sági frissítések folyamatos letöltése. A két utóbbit (tűzfal és 
autoupdate) az XP SP2 automatikusan segít beállítani és a ví- 
ruskereső szükségességére is figyelmeztet. 

A harmadik , lábat" nekünk kell alátenni, mondjuk azzal, hogy 
letöltjük és telepítjük a Microsoft AntiSpyWare alkalmazást. 
Ilyenformán karbantartott munkaállomással (és ésszerű bön- 
gészéssel) fenntartható egy olyan biztonsági szint, amely 
megvédi a rendszert az ártalmaktól. Miért említem az éssze- 
rű böngészést? Nos, senki se csodálkozzon, ha ,kémprog- 
ramtalálkozó" szerveződik a gépén, mert nem tud elszakad- 
ni kedvenc , warez" oldalaitól! A használt programokat is 
érdemes inkább biztos helyről beszerezni, letölteni! Miért 
gondolná bárki is, hogy az internet feketepiaca bármiben kü- 
lönbözik a valós élet feketepiacaitól? Itt is ugyanolyan rizikós 
bármit venni/elfogadni, mint ott, és persze garanciát sem 
várhatunk semmire. Mindenképp szerencsétlen szituációnak 
tartom, hogy a túlzott sokrétűséget és a ,mindent-egyszerre- 
támogassunk" filozófiáját követve az Internet Explorer jelen- 
legi verziói egy sor biztonsági hiba előtt nyitnak sajnos ka- 
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put. Ám ha minden beállítás túl szigorú lenne, akkor meg az 
egyszerű felhasználó nem tudna boldogulni. A legjobb 
megoldás itt is, mint sok más esetben, az arany középút. 


A fejlesztők szemszögéből 

Ez egy hálátlan témakör. Mivel itt is rengeteg megközelítési 
irány létezik, nagyon nehéz megtalálni azt a közös nevezőt, 
ami mindenkinek megfelel. A szabványok ,nem egyforma" 
átvétele illetve megvalósítása azt eredményezte, hogy egy- 
egy korszerű, gondosan megtervezett weboldal legalább há- 
romféleképpen van megírva, hogy minden böngészőtípus 
igényeit ki tudja elégíteni. Vagyis, ha a kedves megrendelő- 
nek - jogosan - az a kívánsága, hogy mindenféle böngésző- 
ben ugyanúgy nézzen ki egy bonyolultabban megálmodott 
website, bizony a programozóknak el kell készíteniük a több- 
féle változatot. Ez jelentős többletmunkát és nem utolsó sor- 
ban többletköltséget jelent! Talán ha a gyártók közelednének 
egymáshoz, illetve a kidolgozott szabványokhoz, ez a prob- 
léma is megoldódna. Ennek okán a beharangozott 7-es Exp- 
lorer verziónak fejlesztői szemmel is nagy elvárásoknak kell 
eleget tennie. A sokat vitatott CSS (Cascade Style Sheets) 
böngészőprogramonként éppen csak egy kicsit eltérő értel- 
mezéséből adódóan, igencsak jelentős mennyiségű anyag 


gyűlt már össze a fejlesztői témájú fórumokon. Egy problémá- 
sabb esetben ezek átolvasása, értelmezése szintén plusz 
idő, ami alatt például folytatódhatna a tényleges fejlesztés. 


Összegzés 

Nem célom az eltérő vélemények egyikét sem erősíteni, sem 
gyengíteni. Pusztán csak azt érdemes tényként elfogadni, 
hogy az a gyártó, aki elmondhatja magáról, hogy a világon 
több millió PC-n fut az operációs rendszere — beépített bön- 
gészővel — annak igenis van joga a szabványokat alakítani, 
formálni. Más kérdés, hogy egyes irányok vezethetnek tévút- 
ra is, amelyek gyors, rugalmas felismerésével megelőzhető 
egy-egy probléma. Talán ezt hivatott majd az új Explorer 7-es 

megoldani. 
A jelenlegi Explorer 6-os is tökéletesen alkalmas arra, amire 
való, mindenféle megjelenítési metódussal képes megbir- 
kózni, ismeri a vonatkozó szabványokat, és nagyvállalati 
környezetben az egyetlen olyan jó megoldás, amely szerve- 
sen illeszkedik a már meglévő, központilag szabályozott 

struktúrába. 
FÜZESI SZABOLCS 
fiszesiszánosi.bu 
MCSA 





Microsoft Újdonságok 


a CeBI1T-en 


, Your Potential. Our Passion." azaz ,Neked 

lehetőség. Nekünk kihívás." jelmondat jegyében 

mutatta be újdonságait az idei CeBIT-en a 
Microsoft. A mottó a vállalat küldetésének rövid és tömör 
összefoglalása. Azt fejezi ki, hogy a Microsoft olyan új 
eszközöket igyekszik fejleszteni, melyek révén segítheti az 
embereket — lehetőségeik  kihasználásában, céljaik 
elérésében, a magukban rejlő képességek kiaknázásában. 
A CeBIT-en jelentette be a Microsoft, hogy a Windows XP 
Media Center Edition alapú PC-k idén további 20 ország fel- 
használói számára válnak elérhetővé. Ennek révén 2005 
végére a Windows XP Media Center Edition már több mint 30 


m 
a 


országban és 17 nyelven lesz kapható. Hannoverben mutat- 
ták be az online együttműködést elősegítő új megoldást, a 
Microsoft Office Live Collaboration Platform-ot, amely a vál- 
lalaton belüli valamint a különböző vállalatok közötti valós 
idejű együttműködést támogató szervereket és kliens oldali 
termékeket foglalja magában. Bejelentettek új, valós idejű 
kommunikációt lehetővé tévő eszközöket: a Microsoft Office 
Live Meeting és a Microsoft Office Live Communications 
Server 2005 termékeket. Találkozhattak az érdeklődők az 
Istanbul kódnéven ismert Universal Instant Messaging 
Client, azonnali üzenetkezelést lehetővé tévő ügyfélprogram 
béta verziójával is. 


ASP.NET 2.O(wWhidbey) 


III. RÉSZ 





szolgáltatásaival 


Bevezetés 
Új hardverre lesz szükség, a mostani már nem bírja a terhe- 
lést! Nagyon gyakran hallom ezt az (áljérvet fejlesztőktől, mi- 
közben csupán napi pár ezer felhasználót szolgál ki a webal- 
kalmazásuk. Sokszor óriási tartalékok lapulnak még a szeren- 
csétlen ócskavasnak nyilvánított hardverben, csak éppen ki 
kell használni őket. 

Nemrégiben a NetAcademia webkiszolgálója is teljesítmény- 
gondokkal küszködött, de az ASP.NET Cache és az If- 
Modified-Since http fejléc felhasználásával sikerült újra 
10 százalék alá vinni a processzor terhelését. (Egyébként egy 
300 MHz-es, P3-as ,monstrumról" van 
szó, ami egy leselejtezett 99-es tanfo- 
lyami hallgatói gép volt. Tényleg.) 


A teljesítmény- 
problémák okai 

A leggyakoribb ok általában az adatbá- 
Zis-lekérdezések lassúsága illetve a kül- 
ső eszközökkel kapcsolatos műveletek, 
mint a fájlműveletek vagy valamilyen 
hálózati kommunikáció. Ez utóbbira 
egyre gyakoribb példát szolgáltatnak JEL 
a Webszolgáltatás hívások. 

Sok problémára látszólag kézenfekvő megoldás lehet aszink- 
ron műveletek használata, azonban webalkalmazások esetén 
ez nem mindig könnyen járható út. Ha például egy Webszol- 
gáltatást kell meghívni, akkor hiába bízzuk rá a hívást egy má- 
sik szálra, a fő, weblapot futtató szálat általában úgyis blok- 
kolni kell, amíg meg nem érkezik a válasz a másik szálra. Ez- 
zel viszont blokkoljuk az ASP.NET egyik munkaszálát és 
az aszinkron híváshoz még egy plusz szálat is a Thread- 
Poolból. Mindkettőben csak pár tucatnyi szál lehet, így egy in- 
tenzíven terhelt rendszerben totális csődöt mondhat a profin 
kidolgozott aszinkron megoldásunk. 

Az aszinkron hívásokat meg lehet oldani anélkül, hogy szám- 
talan szálat pazarolnánk a hívás végére várakozva, ehhez 
még támogatást is kapunk az ASP.NET 2.0-ban, az Async 
Page direktíva képében. Egy későbbi számban még foglal- 
kozom ezzel, a téma iránt érdeklődők az Asynchron HTTP 
Handler kulcsszavakra keresve találhatnak cikkeket az inter- 
neten (főleg 1.1-re). Maradjunk a szinkron megoldásoknál. 
Az adatbázislekérdezések teljesítményét drámai módon lehet 





Teljesítményproblémák 
esetén két-három nap 
alatt csodákat lehet 


művelni némi odafigye- 
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Életszagú teljesítményfokozás az ASP.NET Cache 


fokozni megfelelő indexekkel, a lekérdezések átírásával, egy- 
szerűsítésével, a probléma újragondolásával (pl. nem 
biztos, hogy minden látogató számára tízezer sort kell leválo- 
gatni, úgyse érdekli őket). Némi indexelt view, egy-két tábla 
denormalizálása, sőt sokszor pont a normalizálás is sokat 
segíthet. Pl. ha sokszor szerepel lekérdezésekben a SELECT 
DISTINCT " FROM blah, akkor nem kellene esetleg felvenni 
a hiányzó blah táblát az adatbázisba és így normalizálni 
az adatbázismodellt? Vagy biztos kell a SELECT ", nem 
lenne elég valójában csak két oszlop a kombóbox feltöltésé- 
hez? Tényleg jó, ha lejön még feleslegesen 50 oszlop, al- 
kalmanként 500 kbyte adatforgalmat 
okozva? 

Nem olyan nagy dolgok ezek, két- 
három nap alatt csodákat lehet művelni 
célirányos odafigyeléssel. Gyakori 
az, hogy a munka hevében nem rakunk 
fel olyan indexeket, amelyek hiányát 
utólag nagyon könnyű felismerni, tehát 
érdemes pár órát rászánni a vizsgáló- 
dásra. A módszer nagyon egyszerű. 
Minden lapot futtassunk le realisztikus 
paraméterekkel és nézzük meg SOL 
Server Profilerben a lefuttatott SOL pa- 
rancsokat illetve tárolt eljárásokat. Amelyik végrehajtási ideje 
(Duration oszlop) nagyobb pár száz millisecundumnál, azt ér- 
demes megvizsgálni. Ha sok sort visszaadó lekérdezésről 
van szó, akkor természetes a nagyobb végrehajtási idő, de 
pár tíz sornál általában nagyon kevés, akár 10 ms alatt (gyak- 
ran 0) kell látni. 

Ha egy lekérdezés által olvasott (8 kbyte-os) lapok száma, 
amelyet a Reads oszlopban láthatunk, nagyobb pár ezernél, 
szintén gyanúra adhat okot. Egy tízezer lapolvasást kiváltó le- 
kérdezés lehet, hogy néhányszor 10 millisecundum alatt fut 
le, de biztosak lehetünk benne, hogy egy erősen terhelt szer- 
veren az ilyen lekérdezések fogják lefullasztani a szervert, és 
a végrehajtási idejük is fel fog szökni akár több tíz másod- 
percre is, gyakran időtúllépést okozva a hívókon. 

Konkrét példánkban, a tudástárban [1] jó pár lekérdezés volt, 
amelyet néhány index-szel alaposan fel lehetett gyorsítani. 
Élő, sokak által használt rendszert hangoltam, ilyenkor jól le- 
het azonosítani azokat a sokak által használt lekérdezéseket, 


amelyekkel látványos eredményeket lehet elérni. 
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Profilerrel egy nap termését SOL táblába mentve néhány SOL 
paranccsal könnyedén kielemezhetők a lassú illetve gyakran 
futtatott lekérdezések. A gyakran használtakkal mind a szer- 
ver erőforrások csökkentése miatt, mind a felhasználók által 
érzékelt késleltetések lefaragása céljából mindenképpen ér- 
demes foglalkozni. Összeszoroztattam a napi végrehajtások 
számát (COUNT(")) és a végrehajtási időt (Duration), és a leg- 
nagyobb összköltségű öt lekérdezést optimalizáltam. Voltak 
olyanok, amelyeket nehéz volt együtt optimalizálni, mert 
mindkettőt csak clustered index-szel tudtam volna felgyorsí- 
tani, amiből egy táblán csak egy lehet. 

Ezért örültem, hogy már SOL Server 2005 volt a háttéradat- 
bázis, mert abban egy nonclustered indexet ún. included 
oszlopokkal felvértezve két clustered indexhez hasonló telje- 
sítményt tudtam elérni. Igaz, ezt a módosítások kárára tettem, 
de esetünkben ez nem volt gond, mert napi pár 10 módosí- 
tás van csak a rendszerben. 

Sajnos maradtak olyan lekérdezések, amelyek költsége jelen- 
tős volt, de nem lehetett optimalizálni: a BLOB-okat lekérde- 
ző SELECT-ek. 

A BLOB a Binary Large Object rövidítése, az image, text 
és ntext típusú oszlopokban tárolt maximum gigabyte mére- 
tű adatokat értik alatta. Mi a tudástárba bepostázott képeket 
és egyéb feltöltött fájlokat tároljuk SOL Serverben. Hogy ez 
a megfelelő tárolási mód vagy a fájlrendszer -- adatbázis, 
az vita kérdése, esetünkben az egyszerűbb backup és a ga- 
rantált adatépség érdekében döntöttünk az adatbázis mellett. 
A BLOB-okat egy asp. net lap tölti be adatbázisból és szolgál- 
ja ki a megjelenítő lapok részére. Ehelyett egy saját HTTP 
Handler lenne a jobb megoldás, mivel az aspx lapoknak van 
egy jelentős saját költsége, ami szükséges, ha html tartalmat 
generálunk ASP.NET vezérlők segítségével, de semmi hasz- 
na direkt tartalomgeneráláskor. Ez a következő tudástár ver- 
zióban változni fog. 

Első körben ez a lap (download.aspx) minden kérés esetén 
benyúlt az adatbázisba, lehozta a kívánt tételt, és kipakolta 
azt a kimenetére. Ez jelentős terhelést okozott az SOL Server- 
en, ráadásul olyan terhelést, amelyet indexeléssel nem lehet 
javítani. Ha egyszer egy kép 200 kbyte, akkor akárhogy 
is trükközik a szerver, csak fel kell olvasni és vissza kell külde- 
ni az ügyfélalkalmazásnak. 

Jobban belegondolva azonban teljesen feleslegesen dolgo- 
zott az SOL Server. A letárolt BLOB-ok praktikusan soha nem 
változnak meg (évi néhány törlés maximum, módosítás soha). 
Ha már egyszer lekérdeztünk, jó lenne letárolni őket valami- 
vel közelebb az ügyfélhez (aspx lap), mint az adatbázis. Itt 
az ideje bevetni az ASP.NET Cache-t. 


Az ASP.NET Cache 

A Cache első ránézésre nagyon hasonló a korábbról ismert 
Application objektumhoz. Globális egy webalkalmazásra néz- 
ve, azaz minden lap ugyanazt a Cache objektumot látja. 
A Cache azonban szándékosan feledékeny: a belerakott tar- 
talmat időnként elfelejti. Alapvetően akkor kezd el takarítani, ha 
memóriakényszere van. Hogy ez hány százaléknál következik 
be, arra nincs ráhatásunk, sőt ismeretünk se, bíznunk kell ben- 
ne, hogy nem túl agresszíven allokálja a memóriát kiéheztetve 
más processzeket (eddig ennek nincsenek jelei). Emellett be 
lehet állítani, hogy egy bizonyos időpontban essen ki egy tétel 
belőle, például a következő órában, ha tudjuk, hogy a forrás- 
adatokat mindig óránként frissítik. Ez az Absolute Expiration. 


Használható a Sliding Expiration is, amelyben egy tétel x idő 
múlva kiesik a tárból, de az időzítő újraindul, ha időközben 
mégis felhasználták, kiolvasták a tartalmát. 

Ami azonban sokkal izgalmasabb, az a Dependency-k hasz- 
nálata. Gyakori, hogy a cache-ben tárolt adat fájltartalom, 
XSLT, XML, valamilyen szövegfájl, egy konfigállomány, stb. 
A cache-ben ezek jól érzik magukat, hisz sokkal gyorsabb 
egy referenciát visszakapni a beolvasott tartalomra a Cache- 
ből, mint az operációs rendszeren áthaladva felolvasni őket. 
Igen ám, de ezeket a fájlokat menet közben megváltoztathat- 
ják, ilyenkor azonnal ki kellene dobni a tartalmukat a Cache- 
ből. Erre valók a CacheDependency-k. 

Az ASP.NET 1.x-ben fájlokra, könyvtárakra és másik Cache 
tételre lehet építeni függőségeket. Az első kettő esetén a File- 
SystemWatcher osztály segítségével a Cache monitorozza 
a fájlrendszert, és ha a megadott fájl vagy könyvtár változik, 
akkor kidobja a tételt a memóriából. Utóbbi egymástól függő 
tartalom illetve az Output Cache szabályozására használha- 
tó, erről még lesz szó a cikk következő részében. 

Nézzünk egy fájlrendszer alapú példát: 


DataSet cachedData - (DataSet)Cache[,d"]; 
if (cachedData -—— null) 
ú) 
Cache[,d"] - dg.DataSource - LoadFromFile() ; 
§ 
else 
it 
dg.DataSource - cachedData; 
p 


string dataSourcePath - 
HttpContext . Current . Server . MapPath( , -/emps . xml1" ) ; 


private DataSet LoadFromFile() 
( 
DataSet ds - new DataSet() ; 
ds .ReadXm1 (dataSourcePath) ; 
return ds; 


) 


Nagyon fontos, hogy NEM így kell csinálni! 


//Rossz megoldás 
if (Cache[,d"] -— null) 
( 
Cache[,d"] - dg.DataSource - LoadFromFile() ; 
) 
else 
ú 
7//1!! Mire ideérünk már lehet, hogy kiesett 
//a Cacheből az adatunk !!! 
dg.DataSource - Cache[,d"]; 
) 


//BUGBUG 


Ha azt akarjuk, hogy az emps.xmI változásakor azonnal kies- 
sen a tartalom a Cache-ből, akkor be kell vetnünk a Cache- 
Dependendcy-t: 


Cache. Insert(,d", cachedData, 
new CacheDependency(dataSourcePath) ) ; 


Mekkora adatokat lehet a Cache-be rakni? Sokáig sulykolták 
a fejünkbe, hogy az Application és a Session objektumokat 
ne használjuk nagy fájlok, RecordSetek, DataSetek tárolásá- 
ra, mert hamar elfogyasztjuk a webszerver memóriáját. 


A Cache egy kicsit más állatfajta. Ezt elég gátlástalan módon 
lehet használni, hisz elvileg úgyis kiveti magából a felesleget. 
Ennek ellenére azért észnél kell lenni ezzel is, ha túl gyorsan 
tárolunk el benne nagy objektumokat, akkor előfordulhat, 
hogy nem tudja elég gyorsan kidobálni őket, és elfogy 
az ASP.NET memóriája. Ez csak extrém körülmények között 
állhat elő, és csak azért mondom el, hogy később ne úgy 
jöjjön vissza, hogy , Soci azt mondta", bátran olvassuk fel má- 
sodpercenként a driver.cab-ot (50 mega) és rakjuk be 
a Cache-be. o 

Tény viszont, hogy pár megabyte-os DataSetekkel nem kell 
szívbajosnak lennünk, bátran pakoljuk bele őket a Cache-be, 
ha egyébkéntis a felhasználók számára osztott adatokról van 
szó. Minden egyes felhasználó (Session) számára ennyi infót 
letárolni viszont már valószínűleg sok lenne a Cache számá- 
ra is, ezt Önnek, kedves Olvasó, nem ajánlom. 

Tudástár példánkban adatbázisban tárolt fájlokat szeretnénk 
Cache-elni. Maximum pár száz fájlról van szó, melyek mére- 
te legfeljebb 256 kbyte. Így 300 darabbal számolva legfeljebb 
77 Mbyte-nyi adatot akarunk a Cache-be rakni, ez nem sok, 
ha a szerverben van elég memória, amely esetünkben 512 
Mbyte. Az adatbázisban tárolt fájlok megjelenítéséhez fontos 
azok néhány egyéb jellemzője is, ezért a Cache-be nem csak 
a fájlokat reprezentáló byte tömböket, hanem egy adatleíró 
struktúrát helyezünk el: 


private class ContentDescriptor ( 
public byte[] Content; 
public string ContentType; 
public string ContentName ; 

; 


A Cache-kezelés logikája azonos az XML-es példánál látott 
módszerrel: megnézzük benne van-e a tartalom, ha nincs, 
belerakjuk, ha benne van, kiolvassuk. 


//Adatbázis-tartalom Cache-elése 
//ia: a tartalom azonosítója, int típusú 
ContentDescriptor contentDesc -— 
(ContentDescriptor) Cache[,D" 4 id.ToString()]; 
if (contentDesc -—— null) ( 
//mincs benne a cache-ben 
contentDesc - LoadFileFromDatabase ( ) ; 
Cache[,D" 4 id.ToString()] - contentDesc; 
) 
Response . ContentType - contentDesc .ContentType; 
Response . BinaryWrite (contentDesc . Content) ; 


Az éles kód ennél valamivel hosszabb, mivel fel kellett készí- 
teni hibás helyzetekre is, pl. amikor a megadott id-vel nincs 
is az adatbázisban a letöltendő adat. Hogy ekkor mi történik, 
érdemes megnézni az éles verzióban. O 

Működő, de az eredetihez képest egyszerűsített és a pubs 
adatbázisra átírt példa a [2] címen található meg. 

A Cache-módszerrel sikerült jelentősen csökkenteni az adat- 
bázis terhelését. A memória-felhasználást megfigyelve na- 
gyon érdekes volt látni, ahogy az ASP.NET Cache és az SOL 
Server Buffer Manager (Cache kezelő) egymással versenyzik 
a memóriáért. A szerverben az 512 megabyte memóriáért 
egy SOL Server 2000, egy SOL Server 2005, egy Exchange 
2000, IIS, Apache és számos egyéb folyamat küzd. Mind 
az SOL Serverek, mind az ASP.NET Cache igyekszik élni a 
szabad memóriával. A teljesítményszámlálókat megfigyelve 
látszott, hogy az ASP.NET Cache mérete pár perc használat 


után felment pár 10 tételre, miközben az SOL Server össze- 
húzta magát, azaz elengedte az általa Cache céljára használt 
memória egy részét. Ezek után egy nagyobb lekérdezésre 
az SOL Server harapott egy nagyobbat a RAM-ból, mire 
az ASP.NET Cache elengedte tételeinek egy részét, hadd 
örüljön az SOL Server (meg persze más egyéb folyamatok). 
Azóta is szépen játszanak egymással. Persze egy nagyobb 
szerver esetén az SOL Server maximális memóriafelhaszná- 
lását lejjebb venném, így nem kellene versengeniük egymás- 
sal, de egy ekkora vason és ilyen sok processz esetén nincs 
értelme ennek. 


Amikor a Cache nem elég 

Hiába a Cache mágia, bár a kiszolgáló terhelése jelentősen 
csökkent, böngészőből nézve mégse lettek gyorsabbak a la- 
pok. Képzeljük el azt, hogy egy oldalon van öt kép, mindegyik 
az előbbi dinamikus letöltéssel egy aspx lap kimenetéből csu- 
rog ki (downloadtest.aspx). Mivel alapesetben az aspx lapok 
kimenete logikailag azonnal lejár, hisz dinamikus tartalomról 
van szó, ezért amikor ránavigál valaki az oldalra, minden kép 
újra letöltődik, aböngésző nem meri letárolni a tartalomgene- 
ráló aspx lap által küldött tartalmat. Ilyenkor ugyanis az 
ASP.NET a következő fejléceket küldi aböngészőnek (megfi- 
gyelésük: [3]: 


Kérés: 

GET /WebSite1/download. aspx? id-0736 HTTP/1.1 
Válasz: 

HTTP/1.1 200 OK 

Date: Tue, 22 Feb 2005 01:03:40 GMT 

Server: Microsoft-IIS/6.0 

X-AspNet-Version: 2.0.50203 

Cache-Control: private 

Content-Type: image/bmp 

Content-Length: 643 


A Cache-Control: private jelentése: útközben a Proxy-k nem 
tárolhatják a tartalmat, de a böngésző igen. Ennyi alapján 
azonban még nem tárolja el a letöltött képet a böngésző, mert 
nem tudja meddig érvényes az, így nem meri megkockáztat- 
ni, hogy régi tartalmat jelenít meg. Látszólag ezen könnyű se- 
gíteni, csak le kell küldeni HTTP fejlécekben, hogy a tartam 
tárolható. Az ASP.NET OutputCache direktíva automatikusan 
képes erre: 


c90 OutputCache Duration-"864000"7 VaryByParam- 
RAB ÉS 


A fenti sort egy aspx lap elejére elhelyezve azt közöljük 
az ASP.NET-tel, hogy 864000 másodpercre, azaz 10 napra el- 
tárolhatja a lap legenerált kimenetét az OuputCache-ben, 
amely az eddig tárgyalt Cache egy részhalmaza. Első ráné- 
zésre nem triviális módon ez nem csak azt eredményezi, 
hogy az ASP.NET letárolja a generált tartalmat a szerver me- 
móriájában, hanem ezzel együtt olyan fejlécet is küld az ügy- 
feleknek (akik általában böngészők), hogy barátom, 10 napig 
nyugodtan tárold a neked küldött adatokat. 

A direktíván használható Location attribútum szabályozza 
a lehetséges tárolási helyeket: 


Location-"Any ] Client ] Domstream ] Server I 
ServerAndClient ] None" 


I 











Alapesetben az Any beállítás működik, mindenki Cache-elhet. 
Így a szerver Cache-el, ezzel az egymás után érkező böngé- 
szőknek kis költséggel képes kiszolgálni a tartalmat, ha pedig 
egy böngészőnek újra szüksége van a tartalomra, de az már 
le van töltve a gyorsítótárába (pl. Temporary Internet Files az IE- 
ben), akkor nem kéri le újra a szervertől. A többi érték közül 
a Downstream a legrejtélyesebb. A szó a böngésző és a kiszol- 
gáló közötti Proxy szerverekre utal. Ez azt jelenti, hogy a Proxyk 
és a böngésző is tárolhatja a már egyszer letöltött tartalmat. 
Összegezve: Any: mindhárom résztvevő Cache-elhet. 
DownStream: a szervert kivéve mindenki, így a Proxy-k és 
a kliens is. ServerAndClient: Proxy-k nem. Az előbbieket 
megismerve azt gondolhatnánk, kidobhatjuk a korábbi házi- 
barkács Cache implementációnkat, hisz az OutputCache se- 
gítségével nulla programsorral megoldható a tartalom kiszol- 
gálásának gyorsítása, ráadásul az OutputCache még a szer- 
veren kívül állókat is képes rávenni a tárolásra, ezzel sokkal 
hatékonyabb megoldást kínálva. 

Persze az élet nem ilyen rózsaszín. 

A korábbi OutputCache sor hatására az ASP.NET a követke- 
ző releváns fejléceket küldi a böngészőnek: 


HTTP/1.1 200 OK 

Cache-Control: public, max-age-863971 
Expires: Fri, 04 Mar 2005 01:06:57 GMT 
Last-Modified: Tue, 22 Feb 2005 01:06:57 GMT 
Vanyaos 

Content-Type: image/bmp 

Content-Length: 643 


Ebből okulnia kellene a böngészőknek, ám a sors fintora, 
hogy az IE nem fogja fel, mit sugallnak neki a fejlécek, és nem 
tárolja le a tartalmat, így minden egyes Refreshre újra leszív- 
ja a dinamikusan generált tartalmat. Lehet, hogy ez csak az 
én gépemen probléma, de én így jártam. 

A Mozilla Firefox örömmel engedelmeskedett a cache fejlécek- 
nek, és emiatt azon látványosan gyorsabban töltődnek be azok 
a lapok, amelyeken sok dinamikusan generált kép van. Az 
alábbi lappal teszteltem a böngészőket (downloadtest.aspx): 


cbody? 
cimg src-"download.aspx?id-0736" /2cbr /2 
cimg src-"download.aspx?id-0877" /2cbr /? 


c/body? 


A webszerver logjában ezt láthatjuk: 
Firefox: 


02:00:24 GET /WebSite1/downloadtest.aspx - 200 
02:00:24 GET /WebSite1/download.aspx id-0877 304 
02:00:24 GET /WebSite1/download.aspx id-0736 304 


lEG: 


02:00:27 GET /WebSite1/dowmnloadtest.aspx - 200 
02:00:27 GET /WebSite1/dowmnload.aspx id-0736 200 
02:00:27 GET /WebSite1/download.aspx id-0877 200 


A Firefox kérésére a webkiszolgáló valami , furcsa" 304-es 
kóddal válaszol, míg az IE kérésére egyszerűen visszaadja 
választ. A különbség abban van, ahogyan a kéréseket meg- 
fogalmazzák a böngészők. Hamarosan kiderül mi ez. 


Valami olyan megoldás kellene, amely egyrészt megy IE-vel 
is, másrészt olyan okos is, hogy képes legyen lekezelni azt 
a helyzetet, ha frissül az adatbázisban tárolt tétel tartalma, így 
a forgalom minimalizálása mellett mindig friss tartalmat kap- 
nak az ügyfelek. A megoldás kulcsa a Firefox által helyesen 
alkalmazott az If-Modified-Since header. 


Az If-Modified-Since HTTP header 

Ez a fejléc kiváló szolgálatot tehet a hálózati forgalom csök- 
kentésében. A működése elég egyszerű. A kiszolgáló leküld 
egy fejlécet, amelyben jelzi, hogy a tartalom legutóbbi frissí- 
tési ideje ekkor és ekkor történt, és a tartalom tárolható. 


HTTP/1.1 200 OK 
Cache-Control: private 
Last-Modified: Sat, 01 Jan 2000 08:00:00 GMT 


A böngésző a tartalom második lekérésekor (pl. Refresh 
gomb megnyomása) nem tölti le újra azt HTTP GET metódus 
segítségével, hanem úgy küldi el a kérést, hogy , szerver, 
csak akkor kérem tőled a tartalmat, ha az módosítva van xy 
időpont óta": 


GET /WebSite1/download.aspx?id-1622 HTTP/1.1 
If-Modified-Since: Sat, 01 Jan 2000 08:00:00 GMT 


Ha a tartalom nem változott, akkor a szerver 
ezt válaszolja: 


HTTP/1.1 304 Not Modified 
Content-Length: 0 


Azaz a böngésző csak felszól, van-e frissebb verzió, 
ha nincs, felhasználja a saját Cache-elt tartalmát. Az If- 
Modified-Since lekezeléséhez nincs beépített támogatás az 
ASP.NET-ben, de kézzel implementálni nem nagy tudomány. 
Pontosabban az OutputCache fix értékekkel kezeli, de az IE 
nem hajlandó szót fogadni neki. De a mi megoldásunkat sze- 
retni fogja. 

Figyelni kell a kérésben az If-Modified-Since fejléc jelenlétét. 
Ha jelen van, ki kell venni annak értékét. Az a dátum lesz 
stringként ábrázolva, 0. időzónában leírva, amely a kliens ál- 
tal tárolt tartalom dátumát tartalmazza. A feladatunk ezen 
dátum összehasonlítása a szerveren tárolt tartalom frissítési 
dátumával. Ha a két dátum nem egyenlő, akkor beállítjuk 
a Last-Modified fejlécet a forrás dátumára és beállítjuk, hogy 
a böngésző tárolhatja a tartalmat. Ha a böngészőnél elég friss 
tartalom van, akkor HTTP 304-es kóddal jelezzük, hogy 
a böngésző által tárolt tartalom friss, és nem küldünk neki 
semmilyen tartalmat a HTTP válasz törzsében (ezt láttuk 
a Mozilla kéréseinek logjában). Azaz ilyenkor csak fejlécek 
mennek vissza a böngészőhöz. 

Az előbb leírtak kezelésére létrehoztam egy kis segédosz- 
tályt, amelyet 2.0-s ASP.NET-ben az App. Code könyvtárba 
kell elmenteni: 


public class IfModifiedSinceHelper ( 
private static bool IsCachedVersionOkay( 
DateTime lastModification) ( 
string ifModified — 
HttpContext. Current .Reguest. 
Headers[,If-Modified-Since"] ; 


if (ifModified !- null) ( 
return ifModified —— 
lastModification. ToUniversalTime ( ) 
ToString(.r"); 
J 
return false; 
, 
public static bool HandleHeader( 
DateTime lastModification) ( 
HttpResponse response - 
HttpContext . Current .Response ; 
if (IsCachedVersionOkay(lastModification)) ( 
response .StatusCode — 304; 
response . SuppressContent — true; 
return true; 
) 
else ( 
response . Cache . SetLastModified( 
lastModification) ; 
response . Cache . SetCacheability( 
HttpCacheability. ServerAndPrivate) ; 
//Lehet Public is 
return false; 
J 
) 
h 


A HandleHeader metódusnak át kell adni egy dátumot, amely 
a kérdéses tartalom utolsó módosítási dátumát tartalmazza. 
Érdemes az osztály működését összevetni az előző oldal vé- 
gén található algoritmusleírással. Ha a metódus true-val tér 
vissza, akkor a lapnak már semmi dolga, befejezheti a futá- 
sát. Ha false-szal, akkor le kell generálni a kimeneti tartalmat, 
a fejlécek kezelését már elintézte a segédosztályunk. A ko- 
rábbi adatbázis-tartalom Cache-elése című kódot az alábbi 
módon kiegészítve máris működik az intelligens cachelésünk: 


if (!IfModifiedSinceHelper.HandleHeader( 
new DateTime(2000, 01, 01, 00, 00, 00))) ( 
A korábbi adatbázistartalom Cache-elése kód 
) 


A paraméterként átadott dátummal kicsit csaltam. Ott a tarta- 
lom valós utolsó módosítási dátumát kellene kivennem 
az adatbázisból. Azonban esetünkben egy cikkhez feltöltött 
kép soha nem módosítható, legfeljebb törölhető. Ezért azt ha- 
zudom, a tartalom utoljára mindig 2000. 01. 01-én módosult. 
Más tartalom esetén az adatbázisból kérdeztem le egy adott 
tétel utolsó módosítási dátumát. Általában ez sokkal kisebb 
költségű lekérdezéssel is megoldható, mint a tényleges tarta- 
lom kiolvasása, megszerkesztése. Ezt a megoldást használ- 
tam a tartalmat összegző RSS kimenetnél, amely egy XML 
formátumú leírás a legfrissebb cikkekről. Mivel az RSS tartal- 
mat nem böngészők, hanem RSS Aggregátorok, olvasók töl- 
tik le általában óránként, a Last Modified nélkül nagyon nagy 
terhelést kapott a szerver és ráadásul jelentős, redundáns há- 
lózati forgalmat is generált. Az RSS-hez az utolsó módosítást 
egy egyszerű SELECT MAXf...)-szal lekérdezve és a fenti 
módon a headereket lekezelve fellélegzett a kiszolgáló. 
Az előbbi lekérdezés egy összetett Cover index-szel nagyon 
gyorssá tehető. 


Cache az ASP.NET 2.0-ban 

Az 1.x verzió Cache-ét nagyon szeretjük, de elzárták előlünk 
új CacheDependency-kkel való bővítés lehetőségét, 
a CacheDependency osztály sealed, azaz nem lehet leszár- 
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maztatni belőle. Egy osztályt leszármaztatásra tervezni egyál- 
talán nem könnyű feladat, és az 1.x-ben még nem volt ez fon- 
tos tervezési szempont. Közben azonban kaptak pár évet a 
fejlesztők, így kinyithatták és dokumentálhatták az osztály mű- 
ködését. Azért olyan kritikus egy CacheDependency jó meg- 
valósítása, mert nagyon intim kapcsolata van az ASP.NET 
Cache rendszerével, így ha hibásan működik, megőrülhet tő- 
le a teljes ASP.NET Cache. A kibővítési lehetőséggel az ! 
ASP.NET csapat is élt, és létrehozott egy SalCache- 
Dependency leszármazottat. A neve elég jól jellemzi, őt adat- 
bázis-alapú függőségek felépítéséhez lehet felhasználni. 
Hogyan kell ezt elképzelni? Lekérdezek valamit az adatbázis- 
ból: kérem az 1960 után született alkalmazottak listáját. Tárolom 

az eredményeket Cache-ben. Ezek után elvárom, hogy a 
Cache-ből kiessen a tartalom, ha a lekérdezés eredményhalma- 
Za változik. Vagy ha a lekérdezést alkotó alaptáblák változnak? 
Az első megoldás sokkal finomabb felbontású, de jelentős 
erőforrást igényelhet az adatbázisszervertől az értesítendő 
Cache elemek nyilvántartása és értesítése. A második megol- 
dás viszont elég bután és gyakran kiejti a tételeket a tárból, de 
nagyon kis adatbázis-erőforrásra van szükség a nyilvántartás- 
hoz. A lekérdezés alapú módszer csak az adatbázis-kezelő 
belső támogatásával oldható meg - legalábbis átlagemberek 
számára — ezért az csak SOL Server 2005 alapon fog menni. 

A tábla alapú megoldás működik már SOL Server 7-tel is. A 
táblaalapú módszer működése elég egyszerű. Az adatbázis- 

ra és abban a megfelelő táblákra engedélyezzük a Cache- 
elést az aspnet regsal.exe interaktív (Windows alapú) futtatá- 
sával vagy parancssori paraméterezésével, esetleg program- 
ból az SalCacheDependencyAdmin osztály felhasználásával. 


Adatbázis felkészítésre Cache-elésre: 


aspnet regsgl.exe -E -ed -d Northwind 


A változások követésére létrejön az adatbázisban egy 
AspNet. SalCacheTablesForChangeNotification nevű tábla: 





. tableName nvarchar 450 ] 
notificationCreated — datetime 8 
changeld RG int A 


Egy-egy táblára engedélyezzük a módosítások követését: 


aspnet regsagl.exe -E -et -d Northwind -t Employees 


Az előbbi táblában minden nyomonkövetendő táblához ke- 
letkezik egy sor: 


Employees 3/21/20051T: 


A tábla változtatásait követendő a tábla kap egy triggert: jé 








CREATE TRIGGER 

(Employees AspNet SgiCacheNotification Trigger] ON 
(Employees] 

FOR INSERT, UPDATE, DELETE 

AS ! 
BEGIN 

SET NOCOUNT ON 

EXEC 

dbo.AspNet SgliCacheUpdateChangeldStoredProcedur 
N" Employees" 

END I 











A hivatkozott sp egyszerűen megnöveli a táblához tartozó 
sorban az utolsó, verziót tartalmazó oszlop értékét: 


ALTER PROCEDURE 

dbo.AspNet SglCacheUpdateChangeldStoredProcedure 
E€tableName NVARCHAR(450) 

AS 

BEGIN 

UPDATE 

dbo.AspNet SglCacheTablesForChangeNotification 

WITH (ROWLOCK) 

SET changeld -— changeld t 1 

WHERE tableName - EtableName 

END 


Szimpatikus, hogy a ROWLOCK table hinttel próbálják mini- 
malizálni a nyomkövetés teljesítnménycsökkentő hatását 
az adatbázisra. Látható, hogy a módszer tábla alapú, és nem 
lekérdezés alapú  módosításkövetést tesz lehetővé. 
Az ASP.NET-ben valakinek figyelni kell a tábla változásait, 
mert az SOL Server 7 vagy 2000 nem fog visszajelezni 
az ASP.NET-nek (az SOL 2005 igen!). 

A figyelést, pollozást a web.configban kell beállítani, a konfi- 
gurációs elemek értelme elég könnyen kitalálható. 


csconfiguration xmlnsz 
,http : //schemas .microsoft . com/ .NetConfiguration/ 
4 v2.Oo": 
sconnectionStrings?2 
cadd name-"localNorthwind" 
connectionString-"Data Source-. ; 
Initial Catalog-Northwind; 
Integrated Securityzyes;"/2 
c/connectionStrings?2 


csystem. web? 
ccaching? 
ssglCacheDependency enabled—"true" 
pollTime-"10000" 2 
cSdatabases? 
cadd name-" localNorthwindDB" 
connectionStringName - 
, localNorthwind" /2 
c/databases2 
c/sglCacheDependency? 
£/caching? 
£/system.web? 
c/configuration? 


Ezen hosszadalmas, most nem tárgyalt, de némi security 
konfigurálással tarkított, egyszeri bemosakodás után a füg- 
gőség felépítése már pofonegyszerű: 


Cache. Insert(,d", cachedData, 
new SglCacheDependency( 
. localNorthwindDB" , , Employees")); 


Azaz, amint változik az Employees tábla tartalma, a Cache- 
elt tartalom kiesik a memóriából (10 másodpercen belül). 
Ha a cikksorozatom második részében már ismertetett új 
DataSource objektumokat használjuk adatelérésre, azok au- 
tomatikusan tudják használni az előbb bekonfigurált Cache 
függőségi lehetőséget. 


casp:SgiDataSource ConnectionString-" c9$ 
ConnectionStrings : NorthwindConnectionString1 92" 
SgiCacheDependency-" localNorthwindaDB : Employees" 


Zárszó 

Az igazi csemege az SOL Server 2005 alapú függőségek 
kialakítása, ugyanis azzal pollozás nélkül is megoldható a tar- 
talom eltávolítása a Cache-ből. Következő cikkemben - töb- 
bek között — ezt veszem górcső alá. 


SOCZÓ ZSOLT 

zsolt. soczogo netacademia. net 

A szerző a NetAcademia vezető fejlesztőoktatója 
ASP.NET MVP, MCSE. MCSD, MCDBA, MCT 


A cikkben szereplő URL-e 


[1] netacademia.net/tudastar 
[2] netacademia.net/tudastar/ articlepage.aspx?upid-5233 
[3] www.blunck.info/iehttpheaders.htmi 
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szolgáltatások 6. 


A LOCALSYSTEM 





Haladva a kirakós játékban, ebben a cikkben 15 újabb 


szolgáltatás ismertetése következik, persze továbbrais 


kizárólag a Vindows Server 2003 Standard verziójának 


alapértelmezett telepítése során felkerülő szervizek 


közül. Már csak két rész van hátra ahhoz, hogy a közel 


100 alapszolgáltatás mindegyikét megismerjük. 


iIRSec Services 
(IPSec-szolgáltatások) 

A szerviz rövid neve: PolicyAgent 

Az alkalmazás neve: Isass.exe 

Függés: Remote Procedure Call, TCP/IP Protocol Driver, 

IPSEC Driver 

Függesztés: — 

Porthasználat: TCP: 50 (ESP), 51 (AH), UDP: 500 

(ISAKMP), UDP 4500 (ISAKMP25 NAT-T) 

Alapértelmezett indítás: automatikus 

A Windows 2000-nél ezt a szervizt ,IPSEC Policy Agent" né- 
ven azonosíthatjuk, ám nem valószínű, hogy a névváltoztatás 
sokakat zavarna, hiszen jól ismerjük ezt a szolgáltatást, jól 
cseng a neve. 

Az IPSec egy olyan nyílt szabvány, amelyet a Microsoft kicsit 
felturbózott, így tartományi környezetben, Kerberos v5 hitele- 
sítéssel és akár a Csoportházirendből vezérelve is használ- 
hatjuk. Ez persze nem jelenti azt, hogy e feltételek nélkül nem 
fog működni, sőt, ez annyira nem így van, hogy pl. azon ke- 
vés házirend opciók közé is bekerült, amelyek egy helyi házi- 
rendben is a rendelkezésünkre állnak - azaz tartomány nél- 
kül is alkalmazhatóak. 

Az IPSec alacsony hálózati rétegben működik, és mivel átlát- 
ható (azaz az alkalmazások semmit nem vesznek észre a je- 
lenlétéből), takarékos is, ugyanakkor minimális átviteli sebes- 
ség veszteséggel jár. 

Az IPSec hash algoritmusokkal és a nyilvános kulcsú titkosí- 
tással védi a végpontok közötti kommunikációt. Egy kulcsot 
használ az adatok aláírásához és titkosításához, és egy má- 
sikat az üzenet ellenőrzéséhez illetve a visszafejtéshez. 
Négyféle módszerrel is védelmet nyújthat: 

m Hitelesítés: minden csomagot hitelesít, illetve minden 
csomag eredetét ellenőrzi, ergo garantált, hogy a cso- 
mag attól származik, akitől szeretnénk megkapni (a hi- 
telesítés típusa lehet Kerberos, digitális aláírás, vagy 
egy megosztott titkos kulcs, azaz pl. egy jelszó. 

m Integritás ellenőrzés: az IPSec garantálja azt is, hogy 
nem lehet módosítani a csomagot a végpontok között. 
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m Ismétlés-megtagadás: mivel teljesen egyedi módon ír 
alá minden egyes csomagot, nincs lehetőség újra hasz- 
nálni vagy újraküldeni ezeket. 

m Megbízhatóság: a csomagok titkosítása miatt, csak a 
megfelelő kulccsal rendelkező célpont tudja , elolvasni" 
a tartalmat. 


Az IPSec két protokollt használ: az AH (Authentication 
Header) and ESP (Encapsulating Security Payload) protokol- 
lokat. Az AH autentikál, figyeli az integritást és az újraküldést 
illetve alá is írja a csomagokat az SHA (Secure Hash Algo- 
rithm) vagy az MD5 (Message Digest 5) algoritmus segítsé- 
gével. 

Az ESP mindent elvégez, amit az AH, plusz titkosítis a jó öreg 
DES vagy a fiatalabb és izmosabb 3DES algoritmussal. A két 
protokoll persze kombinálható is, pl. a felhasználási területtől 
(intranet/internet) függően. Fontos szerepe van az ún. IKE 
(Internet Key Exchange) vagy ahogy a protokoll fejlesztője 
Hilarie Orman anno elnevezte: ISAKMP/Oakley (merthogy az 
IKE a IETF, Internet Engineering Task Force [1] elnevezése) 
protokollnak is, ugyanis a felismert titkosítás esetén az IPSec 
driver utasítására előzetesen egyezteti a két fél közötti algo- 
ritmusokat, autentikációt és a kulcsokkal kapcsolatos szabá- 
lyokat egyaránt. 

Az IPSec használata során az igényeink szerint kijelölt gépek 
teljes IP forgalma szűrés áldozatává válhat, így egyszerűen 
meghatározható, hogy az adott kommunikáció engedé- 
lyezett, biztonságos vagy blokkolt-e az IP-címtartományok, 
IP protokollok vagy a megadott TCP és UDP portok alapján. 

Az IPSec-et gyakran használjuk biztonságos csatornák támo- 
gatására illetve kialakítására, azaz pl. VPN kapcsolatnál, akár 
az L2TP protokoll , alá", akár IPSec alagutak formájában (az 
utóbbi pl. az ISA 2004-gyel már viszonylag egyszerűen beiz- 
zítható). 

A szerviz maga tehát a végpontok közötti biztonságot fokoz- 
za, ott áll az IPSec házirendek végrehajtása mögött, kontrol- 
lálja az IPSec driver működését, akár az intraneten, akár a 
nyilvános hálózatokon keresztül. 











Abban az esetben, ha leállítjuk vagy letiltjuk, akkor az IPSec 
alkalmazhatósága természetesen minden folyamatban meg- 
szűnik, más ismert következménye viszont nincs ennek a lé- 
pésnek. 


Kerberos Key Distribution Center 
(Kerberos kulcsszolgáltató) 

A szerviz rövid neve: Kdc 

Az alkalmazás neve: Isass.exe 

Függés: RPC, AFD Networking Support Environment 

Függesztés: - 

Porthasználat: TCP: 88, 544; UDP: 88, 464 

Alapértelmezett indítás: letiltva 

Ez a szerviz kulcsfontosságú, mivel ennek segítségével tud- 
ják a felhasználók a Kerberos v5 hitelesítési protokollt tarto- 
mányi belépésre illetve és használni. A KDC két Kerberos v5 
szolgáltatást is nyújt: 

m Hitelesítés, azaz a TGT-k (Ticket Granting Ticket -— jegy- 
megadó jegy) kibocsátása tartományon belül, illetve a 
megbízható kapcsolatban lévő tartományok között. Er- 
re elsősorban a tartomány szolgáltatásait igénybe vevő 
felhasználónak van szüksége, és azért, hogy egy ún. 
szolgáltatásjegyet tudjon majd kérni a második körben 
a jegymegadási szolgáltatótól (lásd lentebb). A TGT ál- 
talában egy-egy munkamenetre kapható meg, ami az 
alapbeállítás szerint 10 óra (max. 7 nap lehet, a követ- 
kező ábrán látszik, hogy hol lehet állítani a Csoporthá- 
zirendben), de persze ennek lejártakor már egyszerűb- 
ben lehet újra igényelni. 





Ela Adon Ven Hop 
e5]ülmixB e -] 


Detaut Doma Pokcy (alta homenet local] Polcy 









— A) Computer Contiguraton zjErtorce user logon restnehore Ensbled 
63 I Soltware Settingz SZ M axcmum ítetme for ervice beket 600 minuter 
ré pperelyzev ] EJ M avimum lelime for user ticket 10 hoszs 
EE szántai ÉS arám Iícéime for user kckotveneel— 7duge 
8 E Accant Pe kötdis ] EL) Manirmum tolerance for computer clock :ynehi 5 mrutez 


B ZA Password Pokcy 
(8 E Accourt Lockout Pokcy 


a 3] Local Polcier 

íg] EventLog 

[A Rertieted Group: 

00 Syitem Service: 

9 CD Regaty 

19 (0) Fe Syitem 

18 5Y Weless Network NEEE 80211) 

63 (2 Pubic Key Polcies 

8 I Soltware Restnction Pobcies 

6. IP Securly Polcies on Aciíve Dír 
(a CT Adminuttatíve Templates 
za (ff) User Contguraton 





ni 
A Kerberos házirend 


m Jegymegadási szolgáltatás (Ticket-Granting Service - 
TGS$) , azaz a TGT-k , begyűjtője" és ha minden klappol 
akkor a szolgáltatásjegyek kiosztója. Ez utóbbi azért 
fontos, mert ezt , mutatja" be a kliens a kért hálózati szol- 
gáltatásnak. A szolgáltatásjegy a klienst hitelesíti a szol- 
gáltatás számára és vica versa. 
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A hitelesítési folyamat lépései 


A szolgáltatás akkor települ csak, ha a szervert tartományve- 
zérlővé léptetjük elő, akkor viszont biztosan, ergo minden DC 
KDC is egyben (minden tartományi gép meg Kerberos ügy- 
fél is). Ha viszont egy DC-n leállítjuk vagy letiltjuk, az a DC 
nem lépteti be a felhasználókat. 


Logical Disk Manager 
(Logikai lemezkezelő) 

A szerviz rövid neve: Dmserver 

Az alkalmazás neve: dmserver.dll (svchost.exe) 

Függés: Remote Procedure Call, Plug and Play 

Függesztés: Logical Disk Manager Administrative Service 

Porthasználat: — 

Alapértelmezett indítás: automatikus 
A Windows 2000 óta újfajta lemezkezelője van az operációs 
rendszernek, ez pedig a Logical Disk Manager (ami anno a 
VERITAS Volume Manager , könnyített" változataként debü- 
tált). Az LDM feladata detektálni és monitorozni a merevleme- 
zekkel kapcsolatos változásokat és elküldeni a lemez- és kö- 
tetinformációkat a Logical Disk Manager Administrative szer- 
viznek (lásd következő szolgáltatás). Tehát a szerviz figyeli az 
olyan Plug and Play eseményeket, amelyek a merevlemezek- 
kel kapcsolatosak és változás esetén jelez. 
Ha letiltjuk vagy leállítjuk, akkor a dinamikus lemezek állapot- 
és konfigurációs beállításai nem frissülnek tovább és a rend- 
szerbe illesztett új lemezeket sem , veszi észre" a Windows. 
Emellett a Disk Management MMC is randa hibaüzenetekkel 
lep meg bennünket: , Unable to connect to Logical Disk Ma- 
nager service", és így nem is használható tovább. 





Logical Disk Manager 
Administrative Service 






Igálta 
A szerviz rövid neve: Dmadmin 
Az alkalmazás neve: dmadmin.exe /com 
Függés: Logical Disk Manager, Remote Procedure Call, 
Plug and Play 
Függesztés: — 
Porthasználat: — 
Alapértelmezett indítás: kézi, leállítva 
Ez a szerviz az előbb említett jelzések lekezelését végzi. Mi- 
vel kézi indítású, csak akkor indul el, ha elindítjuk a Disk Ma- 


nagement MMC-t vagy ha egy dinamikus lemez állapota 
megváltozik, azaz pl. konvertálás történik, a hibatűrő lemezek 
visszaállítása zajlik, de egy formattálás, illetve a pagefile vál- 
tozása is kiválthatja a szolgáltatás indítását. Ezekben az ese- 
tekben a szerviz tehát elindul, megtörténik a konfiguráció vál- 
tozás, majd a szerviz leáll. 

Ha letiltjuk, akkor a Disk Management MMC ugyanazt produ- 
kálja, mint az előző szolgáltatásnál. 


Messenger 
(Uzenetkezelő) 

A szerviz rövid neve: Messenger 

Az alkalmazás neve: msgsvc.dll (svchost.exe) 

Függés: Remote Procedure Call, Plug and Play, 

Workstation, NetBIOS Interface 

Függesztés: - 

Porthasználat: - 

Alapértelmezett indítás: letiltva 
A Messenger szerviz közismert felhasználású: a konzolról a 
,net send" paranccsal indított illetve az Alerter szolgáltatás 
üzeneteit közvetíti két tartományi gép között (nyilván csak ak- 
kor ha a másikon is elindítottuk ez a szolgáltatást). Lehetőség 
van felhasználók csoportjainak illetve akár egy egész tarto- 
mány összes gépére is üzeneteket küldeni ezzel a szolgálta- 
tással. 
A Windows Server 2003-tól kezdve (a korábbi Windows-ok- 
kal szemben) már alapértelmezés szerint letiltott állapotú. En- 
nek a változásnak az (általam) valószínűsíthető oka egy kriti- 
kus sérülékenység felfedezése lehetett. Ez volt a , Messenger 
Service Spam", amely sok rémületet okozott egy időben, 
ugyanis valóban kéretlen üzeneteket kaphattunk bizonyos 
nyitott portok vagy hiányzó tűzfalak esetén az internet felől, 
éppúgy mintha a belső hálózatról jött volna [2]. 
Ha a szervizt leállítjuk vagy letiltjuk, akkor a felhasználói illet- 
ve szoftveres üzenetek nem kézbesítődnek, a különböző 
programok riasztásai sem. Annyit még célszerű tudnunk er- 
ről a szolgáltatásról, hogy megtévesztő neve ellenére semmi 
köze nincs a Windows/MSN Messenger azonnali üzenetkül- 
dő alkalmazásokhoz. 





Microsoft Software Shadow 
Copy Provider 
(M o t of 
szolgáltató) 

A szerviz rövid neve: SwPrv 

Az alkalmazás neve: swprv.dill (svchost.exe) 

Függés: Remote Procedure Call 

Függesztés: — 

Porthasználat: — 

Alapértelmezett indítás: kézi, leállítva 
Ez a szerviz a Volume Shadow Copy (az ún. Kötetpillanatkép) 
szolgáltatás kiegészítője, azaz, az ezzel a technikával készí- 
tett árnyékmásolatokat kezeli. Mint tudjuk, az árnyékmásolat 
szolgáltatás segítségével egész köteteket illetve megosztott 
mappákat tudunk a hagyományos mentési módszerek nélkül 
is megóvni a véletlen törlésektől és/vagy felülírásoktól, illetve 
az állományok időben különböző változatait is összehasonlít- 
hatjuk ezzel a módszerrel. 
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Shadow copies allow users to view the contents of shared folders 
as the contents existed at previous points in time. For information on 
reguired client software, click here. 
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Shadow copies of selected volume 
2005.02.13. 11:37 
Create Now I 
Delete Now I 
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Az árnyékmásolatokat tartalmazó kötet 
tulajdonságai 


Ia jeg 


resztvevok Properties 


General] Security ] Summary. Previous Versions fi 
! á aj 


File versions 


To view a previous version of a file, select the version 
frorn the following list and then click View. You can 
also save a file to a different location or restore a 
previous version of a file. 


Time 
2005. február 13., 11:37 
2005. február 13., 11:34 


Name 
E) resztvevok 
E resztvevok 
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A kliens opciói 








A használatához szerver oldalon engedélyeznünk kell az 
adott kötet tulajdonságai között, illetve kliens oldalon telepíte- 
nünk kell a szolgáltatás ügyfélprogramját, pl. a kiszolgáló er- 
re a célra létrehozott mappájából, ami a következő helyen ta- 
lálható (de alapértelmezés szerint nincs megosztva): 


Wssystemrootsisystemz2ZVelientsítwelient 
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Az árnyékmásolatok kezelése a vssadmin.exe parancssori 
programmal történik, de sokat segíthetnek a Resource Kit 
kapcsolódó segédprogramjai, pl. a Volrest.exe, amellyel a 
szerver megosztott mappáiban árnyékmásolatokat tudunk 
keresni illetve vissza tudjuk állítani a törölt vagy felülírt állomá- 
nyok előző verzióit. Hasznos eszköz lehet még a szintén a 
ReskKitben található VolPerf.exe (Snadow Copy Performance 
Counters), amely az árnyékmásolatokkal kapcsolatos tete- 
mes mennyiségű teljesítnényszámláló használatát teszi lehe- 
tővé. Ha a szervizt leállítjuk vagy letiltjuk, az árnyékmásolatok 
kezelési lehetősége , kiesik" a kezünkből. 


Net Logon 
(Hálózati bejelentkezés) 
A szerviz rövid neve: Netlogon 
Az alkalmazás neve: Isass.exe 
Függés: Workstation 
Függesztés: — 
Porthasználat: TCP: 139, 888; UDP: 137, 138 
Alapértelmezett indítás: kézi, leállítva (ám tartományi 
tagság esetén automatikusan indul) 


Ez szerviz szintén kritikus jelentőségű, hiszen elsősorban a 
tartományvezérlő és a kliens közötti biztonságos csatornák 
létrehozásáért és fenntartásáért felel. Ez a speciális csatorna 
ahhoz szükséges, hogy megfelelő körülmények között hitele- 
síthesse magát a kliensről a felhasználó (amely folyamat so- 
rán vissza is kapja a DC-től az azonosítóit és a jogosultságait 
5 pass-through) illetve a szolgáltatások is. A számítógépek 
hitelesítésénél is fontos szerepe van, hiszen mindegyik tarto- 
mányi fiókkal rendelkező gépnek szüksége van erre a bizton- 
ságos csatornára. És hogyan jön létre? Egyszerűsítve: a gép 
az LSA segítségével helyileg tárolt jelszava plusz az AD-ben 
tárolt jelszava összehasonlítása után, az adott jelszóval a Net- 
logon szerviz megteremti ezt a biztonságos csatornát. Per- 
sze, ha valamilyen okból már nem passzol a két jelszó (pl. a 
Csoportházirendben megadott változási kényszer hatása 
csak az egyik oldalon érvényesült azaz nem szinkronizálódik 
a jelszó), akkor a gép nem képes arra, hogy hitelesítse ma- 
gát. Eme biztonságos csatorna létezését tesztelhetjük az 


nltest /sc guery:tartomanynev 


paranccsal és ha minden OK, akkor valami hasonló ered- 
mény kapunk: 


Flags: 30 HAS IP HAS TIMESERV 
Trusted DC Name Wa DC neve 
Trusted DC Connection Status Status 
NERR Success 

The command completed successfíully 


0 0x0 


Ha valami bibi van, akkor meg ezt: 


Flags: 0 

Trusted DC Name 

Trusted DC Connection Status Status 
ERROR NO LOGON SERVERS 

The command completed successfully 
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Az nitest.exe a Support Tools csomag része, amelyet külön, 
a telepítő CD-ről kell felrakni (vagy létező SP esetén le kell töl- 
teni, pl. XP SP2 esetén innen [3]). 


Ezen kívül a Windows 2000 Server-től kezdve a Netlogon szol- 
gáltatás egy másik fontos műveletet is elvégez: a DDNS-t fel- 
használva a különlegesen fontos, sokat emlegetett SRV (erő- 
forrás-rekord) rekordokat publikálja a DNS zónákba. Ezért 
hangzik el sűrűn DNS hibák megoldására csodaszerként a 
,net stop netlogon" ill. , net start netlogon" parancs (azaz egy 
NetLogon szerviz újraindítás), amely egy helyes TCP/IP kon- 
figuráció esetén hatásos gyógyszer. Azért az, mert így 
könnyedén újraépíthető egy hosszú nevű és rejtélyesnek tű- 
nő bejegyzésektől (a DC-k szolgáltatásainak, pl. Kerberos, 
GC, LDAP nevét, IP címét, súlyát eláruló rekordok) hemzse- 
gő tartományi zóna a DNS szerverben. Hogy honnan szedi az 
adatokat, amellyel feltölti a zónát? A WyeSystemroot9otsys- 
tem32aconfigmetlogon. dns file-ból, amelyben szépen össze- 
rendezett formában megtalálható minden egyes SRV rekord 
(ezért pl. ha nem lehet DDNS-t használni ezt az állományt kell 
ide-oda másolgatni). 

De meg kell említeni még azt is, hogy a Net Logon szerviz 
felölel pár kiszolgáló generációt, hiszen ennek segítségével 
valósul meg az RPC alapú szinkronizáció az egy NT4-es PDC 
és a BDC-k között. 

Ha netalántán leállítjuk vagy letiltjuk ezt a szolgáltatást, akkor 
ennek a lépésnek valóban kellemetlen következményei lesz- 
nek, hiszen nem működik tovább a felhasználók/szolgáltatá- 
sok hitelesítése, és a DC-k nem tudnak rekordokat regisztrál- 
ni a DNS zónákba. Emellett az adott gépről a tartományhoz 
csatlakozás további problémákat okoz majd, valamint min- 
den további NTLM alapú hitelesítés is megtagadásra kerül, a 
kiszolgáló pedig láthatatlanná válik a kliensek felől. Szóval ne 
kísértsük az ördögöt. 


NetMeeting Remote Desktop 
Sharing 
(NetMeeting távoli asztalmegosztás) 

A szerviz rövid neve: Mnmsrvc 

Az alkalmazás neve: mnmsrvc.exe 

Függés: — 

Függesztés: — 

Porthasználat: TCP: 215, 731, 3389; RDP: 3389 

Alapértelmezett indítás: letiltva 
Kisebb jelentőségű szolgáltatásról van szó, amely csak 
annyit tesz hozzá a lehetőségeinkhez, hogy NetMeeting kon- 
ferenciaszoftver használata közben engedélyezi a Windows 
Asztal átvételét a másik gépről. Ezt a lehetőséget közvetlenül 
a NetMeetingből érhetjük el, és az engedélyezése során a 
szolgáltatás el is indul, illetve a leállításakor letiltásra kerül. 
Ha manuálisan leállítjuk vagy letiltjuk, akkor a szerviz a 
,visszaszívja" a memóriából NetMeeting képernyő meghajtót, 
ergo a távoli asztalmegosztás lehetősége megszűnik. Le- 
gyenis így (azaz maradjon letiltva), valószínűleg semmi szük- 
ségünk nem lesz rá. 


Network Connections 

(Hálózati kapcsolatok) 
A szerviz rövid neve: Netman 
Az alkalmazás neve: netman. dil (svchost.exe) 
Függés: Remote Procedure Call 
Függesztés: Internet Connection Firewall (ICF) / 
Internet Connection Sharing (ICS) 
Porthasználat: — 
Alapértelmezett indítás: kézi, elindítva 


A , Hálózati kapcsolatok" ablakban szereplő , gyári" és álta- 
lunk kreált kapcsolatokkal foglalkozik ez a szerviz. Felel a 
kapcsolatokhoz tartozó beállításokért, a Tálcán lévő kapcso- 
lat állapotjelző ikonokért és az összes többi belső vagy külső 
alkalmazás csak ezen a szolgáltatáson keresztül érheti el az 
adott kapcsolat beállításait. 

Annak ellenére, hogy manuális indítású, mindig elindul auto- 
matikusan, ha van legalább egy hálózati kapcsolatunk. Vi- 
szont ha letiltjuk, annak (többek között) a felsoroltak is követ- 
kezményei lesznek: 


m Nem lehet új hálózati kapcsolatot készíteni 

m A meglevő kapcsolatok ikonjai tovább látszanak, ám 
nem frissíthetőek, nem használhatóak illetve nem konfi- 
gurálhatóak 

m A wxKkapcsolatok állapotüzenetei megszűnnek 

m Az Internet Connection Sharing szolgáltatás leáll 

m A bejövő kapcsolatok/források észlelése (pl. WLAN) 
nem működik 





Network DDE (Hálózati DDE) 

A szerviz rövid neve: NetDDE 

Az alkalmazás neve: netdde.exe 

Függés: Network DDE DSDM 

Függesztés: Clipbook 

Porthasználat: — 

Alapértelmezett indítás: letiltva 
Hálózati támogatást és adatvédelmet nyújt a DDE (Dynamic 
Data Exchange) részére, amely régi ismerős: már a Windows 
2.x óta velünk van. A dinamikus adatcserét (DDE) támogató 
programok adatokat és parancsokat tudnak egymással cserél- 
ni, a NetDDE és a NetBIOS alkalmazásával hálózatban is. 
Alapértelmezés szerint tiltva van, tehát a NetDDE-t használó 
alkalmazások (a hálózat azon másik gépén is, ahonnan a kez- 
deményezés történik) gondban lesznek. Ha szükségünk van 
erre a szolgáltatásra, akkor elég, ha kézi indításúra tesszük, 
mert így csak igény szerint indul majd el, az adott alkalmazás 
kérése alapján. Ebben az esetben a távoli gépről is befo- 
lyásolható a szerviz indítása, tehát ez szintén nem okoz prob- 
lémát. 








Network DDE DSDM 
(Hálózati DDE DSDM) 

A szerviz rövid neve: NetbDEdsdm 

Az alkalmazás neve: netdde.exe 

Függés: — 

Függesztés: Network DDE 

Porthasználat: — 

Alapértelmezett indítás: letiltva 
Az előző szervizhez szorosan kapcsolódó szolgáltatásról van 
szó, ugyanis mielőtt a NetDDE használatba kerülne, az ún. 
NetDDE megosztásoknak valahogyan a rendszerbe kell ke- 
rülniük. Ez a művelet kb. ugyanannyit jelent, mint amikor map- 
pa megosztásokat készítünk, majd a felhasználóknak megen- 
gedjük, hogy kapcsolódjanak ezekhez. A különbség viszont 
az, hogy a NetbDE megosztásokat az alkalmazások többnyi- 
re maguk készítik, bár számunkra is nyitott a lehetőség, pél- 
dául a következő ábrán látható módon, a ddeshare.exe segít- 
ségével. A NetDDE megosztásokat megtekinthetjük a követ- 
kező regisztrációs adatbázis kulcs alatt is: 
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DDE Shares XI 


DDE Shares: 











Műveletek a ddeshare.exe-vel 


Az ilyen típusú megosztások kezeléséhez, a helyi és a meg- 
bízható megosztások nyilvántartásához, azaz egy adatbázis 
üzemeltetéséhez van tehát szükség a DDE Share Database 
Manager-re (más néven erre a szervizre), amelyet viszont ki- 
zárólag a NetDDE szerviz használhat. 

Amennyiben leállítjuk, vagy letiltjuk, akkor a NetDDE adatbá- 
Zishoz nem lehet kapcsolódni, így az ezt igénylő alkalmazá- 
sok működése csorbul. Ha viszont nem használjuk, inkább 
maradjon az alapértelmezett módban, azaz letiltva. 


Network Location Awareness 
(Hálózati hely felismerése) 

A szerviz rövid neve: NLA 

Az alkalmazás neve: mswsock.dil (svchost.exe) 

Függés: AFD Networking Support Environment, TCP/IP 

Protocol Driver, IPSEC Driver 

Függesztés: Internet Connection Firewall (ICF) / Internet 

Connection Sharing (ICS) 

Porthasználat: — 

Alapértelmezett indítás: kézi, elindítva 
Gyűjti és tárolja a hálózati beállításokkal kapcsolatos informá- 
ciókat, mint pl. az IP cím és a tartománynév változás és infor- 
málja a kapcsolódó alkalmazásokat ezekről a változásokról. 
Gyakorlatilag ez az a szerviz, ami lehetővé teszi pl. a Win- 
dows XP óta bevezetett alternatív TCP/IP konfiguráció műkö- 
dését, valamint a gördülékeny (felhasználói beavatkozás nél- 
küli) váltást a különböző WLAN hálózatok között. 
(Kis kitérő: sajnos a vezetékes és vezeték nélküli hálózatok 
közötti váltás nem igazán gördülékeny, gondolok itt arra, hogy 
pl. a vezetékeshez kapcsolódva a WLAN kapcsolat nem vá- 
lik le automatikusan illetve fordítva sem. Egyidejű működés 
esetén meg előjönnek/előjöhetnek névfeloldási és/vagy átjá- 
ró problémák, szóval egyáltalán nem fenékig tejföl. 
Igaz, XP SP2 és a hamarosan elkészülő W2K3 SPT1 esetén le- 
het fékezni az automatizmust azzal, hogy a WLAN kapcsola- 
toknál akár egyesével választhatunk: manuálisra tesszük a 
kapcsolódást vagy automatikussá, de ez még mindig nem az 
igazi, talán majd a Longhorn NLA-val.. . lásd: Longhorn Net- 
work Location Awareness white paper [4]) 
Ez a szerviz is igény szerint indul, ha manuálisra állítjuk. Ha 
viszont letiltjuk az észlelés és a konfigurációváltás értelem- 
szerűen nem fog működni. Az NLA azért is igény szerint in- 











duló szolgáltatás, mert néhány kritikus rendszerkomponens 
is használja (pl. a Winlogon.exe), azaz ha letiltjuk, ezek a 
rendszerkomponensek ezt érzékelik és újra és újra megpró- 
bálják elindítani, amelynek csak egyetlen következménye 
lesz: telefirkálják az eseménynaplót. Leállítanunk is felesle- 
ges, hiszen mindig újra fogják indítani, ezért inkább hagyjuk 
meg az alapértelmezett állapotban. 


NT LM Security Support Provider 
(NT LM biztonsági támogatás 
szolgáltatója) 

A szerviz rövid neve: NilmSsp 

Az alkalmazás neve: Isass.exe 

Függés: services.exe 

Függesztés: Telnet, WINS 

Porthasználat: RPC/TCP 5 dinamikus porthasználat 

Alapértelmezett indítás: kézi, leállítva 
Ez a Windows NT korszakból megörökölt szerviz teszi lehető- 
vé a felhasználók belépését a tartományba abban az esetben, 
ha a LanMan, NTLM vagy az NTLMv2 a hitelesítés módja a há- 
lózatunkban. Ez tipikusan a Windows 9x és Windows NT ope- 
rációs rendszerrel dolgozó számítógépek esetén van így. 
Ha leállítjuk vagy letiltjuk, akkor ezekről a gépekről a tartomá- 
nyi belépés és az erőforrások elérése lehetetlenné válik. 


Plug and Play 
(Plug and Play) 

A szerviz rövid neve: PlugPlay 

Az alkalmazás neve: Services.exe 

Függés: — 

Függesztés: Fax, Logical Disk Manager, Logical Disk Ma- 

nager Administrative Service, Smartcard, Messenger, Te- 

lephony, Remote Access Auto Connection Manager, Re- 

mote Access Connection Manager, Internet Connection 

Firewall (ICF) / Internet Connection Sharing (ICS), Virtual 

Disk Service, Windows Audio 

Porthasználat: — 

Alapértelmezett indítás: automatikus 
Ismerős vívmány a Plug and Play, értelemszerűen ez a szer- 
viz a hardver eszközök felismerését és rendszerbe illesztését 
műveli, zéró vagy minimális felhasználói beavatkozással. Va- 
lóban nagy segítség a feléhasználók számára ez a szolgálta- 
tás, és mára szépen ki is kristályosodott, szemben a Windows 
9x-es hőskorban, amikor még rendszeresen a ,Plug and 
Pray" ( Dugd be és imádkozz") kifejezéssel illették. 
A szerviz kicsit rendhagyó módon működik, mert a Services 
MMC-ben nem lehetséges leállítani vagy letiltani. Ennek oka 
az operációs rendszer stabilitásának megőrzése (nézzük 
meg mennyi szerviz függ a jelenlététől). Ha viszont az mscon- 
fig.exe segítségével mégis leállítjuk, akkor egy újraindítás 
után a Device Manager-ből eltűnnek a regisztrált hardver ele- 
mek. Kipróbáltam, tényleg így van, de nem biztos, hogy jó öt- 
let ezzel játszani, mert nálam például az IntelliMouse driver 
olyan ciklikus Error Reporting manőverbe kezdett, hogy alig 
bírtam újraindítani a gépet. 
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Portable Media Serial Number 
(Hordozható lejátszó sorozatszáma) 

A szerviz rövid neve: WmdmPmSN 

Az alkalmazás neve: mspmsnsv.dll (svchost.exe) 

Függés: — 

Függesztés: — 

Porthasználat: — 

Alapértelmezett indítás: kézi, leállítva 
Végül egy kevésbé izgalmas, ám bizonyos esetekben mégis 
fontos szolgáltatás következik, amely már a Windows 2000- 
nél is létezett, csak másképp hívták (WMDM PMSP Service). 
Ez a szolgáltatás lehetővé teszi a WMDM (Windows Media 
Device Manager) számára, hogy a hordozható média lejátszó 
(mp3 lejátszók, Rio és társai) háttértárait azonosítsa, így a tar- 
talom biztonságos körülmények között lesz másolható. A leg- 
több hordozható háttértár rendelkezik egyedi azonosítóval, 
pl. a CompactFlash (az 1.3-as verziótól felfelé) vagy lomega 
Zip, Jaz és az ún. Clik! lemezek is valamint a legtöbb Smart- 
Media kártya is ebbe a körbe sorolható, ugyanúgy mint az 
újabb és közismertebb típusok is, mint pl. a MultiMedia Card 
(MMC), Secure Digital és a SONY MemoryStick kártyák. E 
procedúra nélkül az ilyen típusú háttértárakkal rendelkező lé- 
vő védett tartalmakhoz hozzáférni nem lehetséges, és ez per- 
sze akkor is bekövetkezhet, ha a szervizt letiltjuk. 





GÁL TAMÁS 
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[1] http:Z/wwwietf.org 

[2] http://www.stopmessengerspam.com/ 
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§ en-us/ dnlong/html/Ihnla.asp 
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SHAREPOINT PORTAL SERVER 2003 - JOGOSULTSÁGOK 


Rovatunkban újra a , csinálj magad intranetet" témát járjuk 


körbe. A Windows ShareFRoint Services és a ShareFkoint 


Portal Server 2003 jogosultságait futjuk át röviden, meg- 


nézzük milyen lehetőségeink vannak felhasználóink jogosult- 


ságainak kezelésére, meghatározására. Hogyan tudunk 


csoportokat kezelni és ezeket hozzáférési, műveleti jogokkal 


felruházni? Mindez hogyan hat a csoportmunka-helyekre? 


vállalati intranetek rohamos tempóval állnak át a 

SharePoint technológia adta lehetőségekre. Az in- 

formációs sztrádák egyre több sávosak lesznek, mi- 
nek következtében az intranetek egyre nagyobb fontosságot 
kapnak egy vállalat életében. Ezért e cikkben megismerke- 
dünk azokkal a koncepcionális nézetekkel, hogy miként le- 
szünk, vagy inkább miként vagyunk képesek a portálhelyeink 
csoporttagságainak jogosultságait kezelni. 
A SharePoint Portal Server 2003 biztonsági beállításai első 
nekifutásra nagyon komplexnek látszanak. Ha alaposabban 
átnézzük ezeket a lehetőségeket, akkor láthatjuk, hogy két- 
három lépésben mégis nagyon könnyen és egyszerűen tud- 
juk a biztonsági beállításokat konfigurálni. Miután végére 
érünk a cikknek, könnyedén felügyeljük cégünk intranetjén a 
SharePoint felhasználói jogosultságokat, hozzáféréseket por- 
tálhelyeinken. Definiálni tudjuk a portálhelyeinket elérő (a por- 
tálhelyhez hozzáférő) felhasználóink jogait. Kezelni tudjuk a 
felhasználókat, csoportokat, és a portálunk elérési útjait. 
Megismerjük röviden a kapcsolódó riasztási, értesítési beál- 
lításokat. 


Csoportok és jogok 

A SharePoint Portal Server 2003 (továbbiakban: SPS), és 
a Windows SharePoint Services (továbbiakban: WSS) alapér- 
telmezett modellként használja a biztonsági csoportokat és 
azok jogait a rendszer egészét tekintve. A portálhely csopor- 
tok tulajdonképpen speciális gyűjteményei a rendszerünk NT 
alapú felhasználóinak és csoportjainak. Minden SPS, és WSS 
biztonsági csoportnak a hozzárendelt biztonsággal kapcso- 
latos kezelési joga van a portálhelyek tekintetében. Képesek 
vagyunk ezeket a gyári biztonsági csoportokat egyszerűen 
módosítani, továbbá hozhatunk létre új biztonsági csoporto- 
kat, vagy akár tetszés szerinti kombinált megoldást is mixel- 
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hetünk. Lépjünk az SPS , Webhely beállításai"-ra (ehhez rend- 
szergazdaként essünk neki portálunknak, és a jobb felső 
sarok felé tekintsünk). Itt az , Általános beállítások" résznél vá- 
lasszuk a , Biztonsági és egyéb beállítások kezelése" menüt. 


Általános beállítások 
TE A portálwebhelyre vonatkozó felhasználók, e 
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Portálwebhely tulajdonságainak és a Shar. 
SharePoint Portal Server - központi felügy 


Tovább haladva a megjelenő oldalon a , Felhasználók és en- 
gedélyek" résznél válasszuk a , Egyhelyes csoportok kezelé- 
se" hivatkozást. Az SPS beépítve tartalmazza az alábbi cso- 
portokat: 

m Olvasó csoport. A csoport tagjai képesek megnézni 
a portálhelyeinken elhelyezett listák, dokumentumtárak 
tartalmát, illetve rálátással bírnak számukra engedélye- 
Zett oldalakra, de csak olvasási joggal. 

m  Munkatárs csoport. A csoport tagjai képesek a kijelző- 
ket listázni, azok tartalmait módosítani, a dokumentum- 
tárakat felügyelni. Képesek továbbá módosítani, illetve 
készíteni saját nézeteket a weblapokon. 

m  Webbelytervező csoport. A csoport tagjai képesek 
az SPS weblapjainak szerkesztésére, listák és doku- 
mentumtárak létrehozására, akár a Microsoft Office 
FrontPage 2003 segítségével. 

m Rendszergazda csoport. A csoport tagjai teljes felügye- 
lettel, korlátozás nélkül rendelkeznek a webhely felett. 
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A csoport minden tagja képes konfigurálni az összes 
beállítást, kezelni a felhasználók és a csoportok jogo- 
sultságait, tagságait. 

m Tag csoport. A csoport tagjai képesek megnézni, módo- 
sítani saját portálhelyeinek tartalmát, illetve ott tartalmat 
készíteni. A tagoknak lehetőségük van további web- 
helyek létrehozására. 

m Tartalomkezelő csoport. A csoport tagjai készíteni tud- 
nak alwebhelyeket, listákat, dokumentumtárakat, to- 
vábbá csoportmunka-helyeket, azaz WSS webhelye- 
ket. 


Egyedi csoportok 

Lehetőségünk van portálhely tulajdonosként vagy rendszer- 
gazdaként egyedi csoportokat létrehozni a gyáriak mellé 
(vagy akár azok helyett). Kattintsunk az ,Egyhelyes csoport 
hozzáadása" gombra: 


zjegyhelyes csoport hozzáadása ] 


A létrehozandó új csoporthoz tartozó jogköröket a rendelke- 
zésre álló 24 alapjog szelektív kiválasztásával egyedileg kon- 
figurálhatjuk annak függvényében, hogy miként szeretnénk 
a csoport tagjainak jogkörét megalkotni. A 24 alapjogot most 
itt nem részletezem, de elégséges a választék az egyéni igé- 
nyek kielégítéséhez. 

Az így definiált és ezáltal életre keltett új csoport tagságának 
megadhatunk tartományi csoportokat, helyi csoportokat, illet- 
ve ezen csoportok tagjait egyenként is felvehetjük csoport- 
tagnak. Ehhez kattintsunk az új csoportunk nevére, és kattint- 
sunk a , Tagok felvétele" gombra. A megfelelő felhasználók 
kiválasztásához egy egyszerű kereső ablak áll rendelkezé- 
sünkre. 
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Jól látszik a folyamatban, hogy ugyanaz a menet áll rendel- 
kezésünkre egy adott felhasználó csoportokhoz való hoz- 
záadásához, vagy egy adott csoport tagjainak kiválasztásá- 
hoz. Ez jó így, hisz nagyban leegyszerűsíti, és átláthatóvá te- 
szi a folyamat kezelését. 

Optimálisan kétféleképpen lehetünk rendszergazdái az SPS- 
nek és a WSS-nek. Önálló szerveren a Windows rendszer- 
gazdai csoport helyi tagjaiként, illetve lehetünk tagjai a Share- 
Point rendszergazda csoportnak a portálon belül. 


Helyi rendszergazda csoport 

A helyi rendszergazda csoport tagjainak joga van végrehaj- 
tani minden olyan adminisztratív funkciót a szerveren, ami 
a helyi szerverre vonatkozik, de csak és kizárólag a helyi szer- 
verre. Ha tartományi rendszergazdák vagyunk, akkor ez a tar- 
tományra értendő természetesen. 


SharePoint rendszergazda csoport 
Minden olyan személy vagy felhasználó, aki tagja a SharePoint 
rendszergazda csoportnak, képes a központi adminisztráció- 
kat elvégezni anélkül, hogy ő a helyi szerveren (vagy a tarto- 
mányban) egyébként rendszergazdai funkciókkal rendelkez- 
ne. Azaz elválasztható egymástól a SharePoint adminisztrációs 
jogosultság az általános Windows NT tartomány adminisztrá- 
ciós folyamataitól. Amennyiben csak a SharePoint adminisztrá- 
tor csoportnak vagyunk tagjai, de a Windows NT tartománynak 
nem vagyunk rendszergazdái, akkor egy ,futtatás másként" 
paranccsal nem tudunk jogosultságot szerezni a szerverün- 
kön. Viszont ha a SharePoint adminisztrációs oldalain tevé- 
kenykedünk, akkor képesek vagyunk új helyet, helyeket létre- 
hozni, módosítani a kvótákat, illetve a hely, helyek egyéb para- 
métereit átállítani. Ha a lokális szerverünk adminisztrátor cso- 
portjában tagok vagyunk, de nem vagyunk tagjai a SharePoint 
adminisztrátor csoportnak, azzal, hogy a lokális szerver rend- 
szergazdái vagyunk, automatikusan SharePoint rendszergaz- 
dákká is válunk egyben. Ez nagyon fontos, mert a Windows 
rendszergazdák (legyenek helyiek, vagy tartományiak) nem 
korlátozhatóak jogkörileg az SPS, vagy a WSS tekintetében. 
Ellenben fordított helyzetben, azaz amennyiben tagjai va- 
gyunk a SharePoint rendszergazda csoportnak, de nem va- 
gyunk tagjai a helyi (vagy tartományi) rendszergazda cso- 
portnak, úgy nem tudjuk módosítani az Internet Information 
Services (IIS) adatbázis beállításait, ahogy a helyi szerveren 
lévő fájlrendszer beállításait sem. Ennek következtében nem 
tudjuk az alábbi műveleteket végrehajtani az SPS, és/vagy 
a WSS rendszereken: 
mu Nem tudjunk kiterjeszteni virtuális szervereinket, azaz 
nem tudunk legfelsőbb szintű webhelyet létrehozni, 
illetve megváltoztatni annak beállításait. 
mum Nem tudjuk visszavonni (uninstall) a SharePoint Servi- 
ces-t. 
m Nem tudjuk kezelni az elérési útvonalakat. 
m Nem tudjuk megváltoztatni a rendszergazdai csoport- 
tagságot. 
mu Nem tudjuk konfigurálni az adatbázis beállításainkat, 
illetve nem tudjuk használni az STSADM.EXE eszközt. 


A SharePoint rendszergazda csoport tagjai képesek végre- 
hajtani minden olyan adminisztrációs feladatot, melyek a köz- 
ponti adminisztrációs oldalakon elérhetők. 

Ez a kettős rendszergazdai jogkör egy kellemes középmegol- 
dás arra nézve, hogy szerverünket biztonságban tudjuk, és 
olyan portál rendszergazdákat jelölhessünk ki magunk mellé , 
akik esetlegesen az alaptechnológiához, mint pl. az SOL 
szerverhez, vagy a Windows szerverhez nem rendelkeznek 
megfelelő képesítéssel, tudással (azaz nem tudják az vélet- 
lenül sem elrontani). Egy ilyen rendszergazda, aki a Share- 
Point rendszergazda csoport tagja, képes törölni a WSS cso- 
portmunka helyeket, illetve minden egyéb olyan tevékenysé- 
get el tud végezni, ami a megfelelő helyek adminisztrálásá- 
hoz feltétlen szükséges, de nem többet. 


Rendszergazdák 

Mint fentebb már említettem, a rendszergazdák az összes 
joggal rendelkeznek, melyek a portálhelyekhez, webhelyek- 
hez szükségesek. 

Vigyázat! Nincs lehetőségünk módosítani, illetve törölni 
a gyári rendszergazdai csoport jogosultsági összetételét, 
viszont adhatunk hozzá és el is vehetünk belőle tagokat. Bár- 
hogy is rendezzük a rendszergazdai csoport tagságát, 
a rendszergazdai csoportban mindig legalább egy tagnak 
lenni kell! A portálhely tulajdonosa és az esetlegesen definiált 
másodlagos tulajdonosa minden esetben a portálhelyhez tar- 
tozó rendszergazdai csoportnak a tagja kell, hogy legyen. 
Nagyon előnyös az SPS jogosultsági szerkezetében, hogy por- 
tálhelyenként mindig definiálva vannak a csoportok külön- 
külön, azaz eltérő lehet portálhelyenként a csoporttagság. Így 
pl. az egyik helyen lehetünk webtervező, a másikon meg csak 
olvasó. Az SPS adminisztrációs feladatai minden esetben elvé- 
gezhetőek bármely portálhelyen, vagy legfelsőbb szintű web- 
helyen, amennyiben a rendszergazdai csoport tagjai vagyunk 
a helyi szerverünkön, vagy esetlegesen a tartományi rendszer- 
gazda csoportban. Hisz ezen helyi rendszergazda csoportok, 
és tartományi rendszergazda csoportok minden esetben köte- 
lezően tagjai az SPS rendszergazda csoportjának ugyebár. 


Felhasználók és csoportok 

Valahol ott tartunk, hogy a rendszergazdák, illetve a rendszer- 
gazdai csoport tagjai minden webhelyen (akár a legfelsőbb 
szintű portálhelyen) képesek kezelni a felhasználók hozzáfé- 
rési és csoporttagsági jogait. Így attól függően, hogy melyik 
felhasználó melyik portálhelyen melyik csoport tagja, ennek 
megfelelően fér hozzá az adatokhoz. Vagy épp ellenkezőleg: 
nem fér hozzá azokhoz. A felhasználókat kétféle módon tud- 
juk hozzáadni a portálrendszerünkhöz, hogy valóban felhasz- 
nálói legyenek annak. A kétféle modell közül csak az egyiket 
tudjuk választani: 

m , Tartományi felhasználó" módban a felhasználók tagjai 
lesznek csoportjainknak feltételezve, hogy a tartományi 
felhasználók már létező felhasználók mondjuk az AD- 
ben. 

m Az , Active Directory (AD) felhasználók készítési" mód- 
ban a létrehozott felhasználók ugyanúgy tagjai lesznek 
az általunk kijelölt csoportoknak, de nem szükséges, 
hogy eredetileg az Active Directory-ban létezzenek. 
Amennyiben így hozzuk létre a felhasználóinkat, a lét- 
rehozáskor automatikusan létrejönnek az Active Direc- 
tory-ban. 


A két mód közül a telepítés folyamán kell választanunk. A ké- 
sőbbiekben nincs lehetőségünk áttérni egyik módról a másik- 
ra. Bármelyik módot is választjuk, minden esetben rendelke- 
zésünkre állnak a HTML felületű rendszergazdai oldalak. 


Tartományi felhasználó mód 

Ha ezt a módot választottuk telepítéskor, úgy a WSS oldalain, 
illetve szervezeti felépítésében a felhasználók minden eset- 
ben Windows tartományi (vagy helyi) felhasználók is egyben. 
Tulajdonképpen így a meglévő felhasználókat tudjuk hoz- 
záadni SharePoint alapú csoportjainkhoz vagy csoportmun- 
ka-helyeinkhez. 

Amennyiben így indulunk neki rendszerünknek, nincs lehető- 
ségünk az AcitiveDirectory-ban létrehozni felhasználókat 


SharePoint portálunkon keresztül. Ez a mód egyébként 
az alapértelmezett működési módja a WSS-nek, és az esetek 
99 százalékában valóban ezt a módot használjuk. 


AD felhasználó készítési mód 

Amennyiben ezt az üzemmódot használjuk, úgy a WSS por- 
tálunkra való ránézéskor automatikusan készül el az AD-ben 
a felhasználó. Ha ezt a módot választjuk a portálunk üzemel- 
tetéséhez, akkor nem tudjuk használni meglévő tartományi 
felhasználóinkat automatikusan. 

Nagyon fontos, hogy az SPS ezt a módot nem alkalmazza, 
csak a WSS. Így nekünk sincs lehetőségünk az SPS esetében 
ezt a módot választani telepítéskor. Általában ezért az apró- 
ságért nem találkozunk ezzel a lehetőséggel az SPS telepíté- 
sekor. 

Amikor ezt az üzemmódot használjuk a WSS esetében az AD 
felhasználók készítéséhez, a belépéskor meg kell adnunk 
a tartományban használandó nevet, a hozzá való e-mail cí- 
met, illetve csoporttagságot. A csoporttagság ilyen értelem- 
ben a SharePoint csoportokra vonatkozik, nem pedig a tarto- 
mányi (helyi) csoportokra. 

A WSS ellenőrzi, hogy az ActiveDirectory-ban van-e már ilyen 
nevű felhasználó (mármint amit épp megadunk), illetve e-mail 
cím, stb. Amennyiben nincs, úgy engedélyezi a létrehozást 
az AD-ben, ellenkező esetben figyelmeztetést ad, hogy 
a megadott paraméterekkel nem lehet létrehozni a belépni 
szándékozó felhasználót. Ha minden adatot sikeresen 
megadtunk, úgy a WSS üzenetben küldi meg a belépési jel- 
szót a felhasználónak a megadott e-mail címre. 
Amennyiben ezt a ritkán használt ActiveDirectory felhaszná- 
ló készítési módot használjuk, a rendszergazdai feladatokat 
nem tudjuk ellátni a HTML adminisztrációs oldalakon. Pl. nem 
tudunk készíteni legfelsőbb szintű webhelyet, nem tudjuk en- 
gedélyezni portálhelyek létrehozását, és nem tudunk felhasz- 
nálókat hozzáadni a központi felügyeleti lapokhoz. 


Központi adminisztrációs oldalak 

Ha rendszergazdái vagyunk a helyi szerverünknek, vagy tag- 
jai vagyunk a SharePoint rendszergazdai csoportnak, akkor 
lehetőségünk van minden adminisztrációs jogot, és azok mó- 
dosítását megtennünk itt a portálhelyeinkre. 

A központi adminisztrációs oldalakról tudunk kapcsolódni 
a portálhelyek saját adminisztrációs oldalaihoz. Valahol itt 
kezdtük a cikket is. Körbeértünk 0. Ezeken az oldalakon tud- 
juk az adott portálhelyhez kapcsolódó jogosultság-módosítá- 
sokat elvégezni, illetve felhasználókat visszavonni, hozzáad- 
ni, módosítani a taglistákat, változtatni a tulajdonosokat. 
Ugyanezen oldalakon módosíthatjuk a portálhelyhez tartozó 
leírásokat, elérési útvonalakat, illetve specifikus, speciális 
beállításokat. Továbbá meg tudjuk nézni, illetve ki tudjuk lis- 
tázni mindazon felhasználókat és csoportokat, amelyek jogo- 
sultsággal rendelkeznek az oldalainkhoz. Az igények alapján 
az új felhasználókat a csoportokhoz, illetve a jogosultsági lis- 
tákhoz tudjuk rendelni. Persze törölni is tudjuk a felhasználó- 
kat és csoportokat, valamint visszautasítani az igényléseket. 
Amikor hozzáadunk egy új felhasználót egy csoporthoz, vagy 
portálhelyhez, lehetőségünk van arra, hogy az SPS szerve- 
rünk e-mailben küldjön értesítést a felhasználónak arról, hogy 
ténylegesen hozzáfér a portálhelyhez. Módunkban áll az 
alapüzenet e-mail formáját megváltoztatni, és/vagy a kérel- 
mekre válaszolni. 
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Ha már említettem az e-mail alapú üzenetküldést, akkor vé- 
gezetül, de nem utolsósorban nézzük meg ezeket az értesí- 
téseket, riasztásokat. 


Értesítések kezelése 

Az értesítések kezelésével foglakozó oldalra úgy jutunk el, 
hogy a , Webhely beállításai" oldalon, az , Általános beállítá- 
sok" résznél kattintunk egy nagyot az ,Értesítési beállítások 
kezelése" hivatkozásra. Pont a biztonsággal foglalkozó link 
alatt. Az elénk táruló oldalon két témában gyakorolhatjuk 
rendszergazdai jogainkat: 


Általános beállítások 


Tü] A portálwebhelyre vonatkozó felhz 
a Felhasználók kezelése 

E Biztonsági és egyéb beállítások 
nm Értesítési beállítások kezelése 
5 Portálwebhely tulajdonságainak 
a SharePoint Portal Server - közp 


Értesítések lehetőségei 

Törölhetjük, vagy visszavonhatjuk a már nem létező, vagy 
üzemen kívül helyezett felhasználók értesítéseit. Visszavon- 
hatjuk az összes értesítést az őket tartalmazó adattárból 
a portálhelyünk összes felhasználójára nézve. Készíthetünk 
kvóta limiteket arra nézve, hogy hány értesítést állíthatnak be 
a felhasználók összességében portálhelyünkön. Azt is beál- 


Tanfolyami akciók! 


Windows 2003 tanfolyamhoz 3096 kedvezmény az Exchange 2003 


és SMS 2003 tanfolyamok árából! 
Kedvezményes MCSD fejlesztői tanfolyami csomagok. 


Új tanfolyamok! 


SharePoint Portal Server 2003, Microsoft Operations Manager 2005, 
ISA 2004 Projektmenedzsereknek egynapos, technológiai áttekintést nyújtó előadások. 


Microsoft SA oktatási kuponok beválthatók 


líthatjuk, hogy hány értesítést állíthat be egy felhasználó ma- 
gának, ahogy azt is, hogy az értesítések hány helyre mehet- 
nek maximálisan üzenetként. A portálhely automatikusan pró- 
bálja optimalizálni az értesítések összességét feladatuktól 
függően. Így amennyiben valamelyik értesítés értelmét veszí- 
ti, illetve hatályon kívül esik, úgy azokat deaktiválja, vissza- 
vonja a rendszerből. 


E-mail értesítések kezelése 
Konfigurálhatjuk az SMTP szervert és engedélyezhetjük a fel- 
használók e-mail-ben történő értesítését. Visszavonhatjuk 
az összes várakozó e-mail értesítést illetve a várakozó üres 
üzeneteket. Módosíthatjuk a felhasználók profiljaiban azt a 
beállítást, ami az alapértelmezett e-mail címet tárolja. Módo- 
sítani tudjuk az üzenet formátumát, kinézetét, illetőleg azt, 
hogy milyen szövegeket tartalmazzon az üzenet. 

Ugye az is jól látszik, hogy a csoport és a rendszergazdai jo- 
gok milyen finom játékokra adnak lehetőséget az SPS és 
a WSS felügyeletére, elérésére nézve. Persze ami a cikkben 
szerepel, az csak egy része az információknak, a lehetősé- 
geknek. Nem említettem például a felhasználók és az AD 
kapcsolatát, illetve a felhasználói profilok kezelését. 


Aki ennél többet szeretne tudni a témáról, az bátran keresse 
fel az IRSOFT - John Bryce Oktatóközpont munkatársait! 


FARKAS VÍKTOR 

IOSOFT - Jobn Bryce Oktatóközpont 
farkas vabotmail.com 

MCSE, MCT, HP-ASE 


IOSOFT- John Bryce 


VETETTEK GRRR T 


IOSOFT—- JOHN BRYCE 
OKTATÓKÖZPONT KFT. 
Cím: Budape 


Web: 
Telefon 
E-mail: tanfc 


Nálunk beválthatja a Microsoft Software Assurance licenc vásárlása után kapott 


oktatási kuponjait! 


További információkért hívja munkatársainkat! 
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NAPI FELADATOK AZ SOL SERVER 2000-REL 


Sok cikk jelent már meg SOL Server témakörben, de eddig 


csupánfejlesztői szemszögből vizsgáltuk az adatbázis- 


kezelést. A többség számára ez a megközelítés teljesen 


haszontalan. Ők azok az adatbázis-rendszergazdák, akik 


egy módosíthatatlan késztermék üzemeltetéséértfelelő- 


sek, abból kell kihozniuk a maximális teljesítményt, azt kell 


karbantartaniuk stb. Nekik szól ez a cikk. 


z SOL-adatbázis egy élőlény: megszületik, felnö- 
vekszik, általában hosszú életút után nyugdíjba vo- 
nul, majd szegényen és elfeledve hal meg valahol 
egy koszos PC-n a sarokban. Élete során adatokkal táplálko- 
zik, meghízik, ettől ellustul, ekkor alakformáló szalonba küld- 
jük, amitől megfiatalodik, ismét fürge lesz. Az eddigiek is szé- 
pen mutatják, hogy igencsak van olyan jellegű teendő vele, 
ami nem igényli az élőlény kibelezését, szívátültetést és ha- 
sonló műtéteket. Ezek a véres dolgok a fejlesztés témaköré- 
be tartoznak. 
Foglaljuk röviden össze, milyen feladatok várnak tehát azok- 
ra, akik egy SOL-alapú alkalmazás boldog tulajdonosainak 
tekinthetik magukat: 
m Üres adatbázis létrehozása, telepítőseript futtatása 
m Felhasználók létrehozása/beengedése adatbázisokba 
m Az adatbázis helyreállítási üzemmódjának beállítása 
(recovery model) 
m Bizonyos adatok publikálása a webre 
m Időzített mentések, indexkarbantartás és hasonló 
feladatok (jobok) készítése 
m  Adatpumpa (export-import) különböző forrásokból, -ba 
m Kritikus hibákról automatikus érte- 
sítés kérése emailben 


Ezek nem mindegyikét fogjuk most 
kielemezni, mert például a legutolsó 
pont, az emailes értesítés megvalósítá- 






Milyen feladatok 


várnak az SOL-alapú 


Az sal kiterjesztésű fájlokat például az SOL Server menücso- 
portjában található Ouery Analyzer segítségével futtathatjuk le 
oly módon, hogy -— megfelelő bejelentkezés után — megnyitjuk 
a fájlt, majd megnyomjuk a kis zöld nyilacskás ikont (execute). 


Ennek a lépésnek két kimenetele lehetséges: 

m Volt a scriptben CREATE DATABASE utasítás, tehát lét- 
rejött az adatbázis, és abba kerültek a táblák. 

m Nem volt benne CREATE DATABASE, így az összes 
tábla és alapadat Master adatbázisban kötött ki. Ez 
igen örömteli esemény, most több órányi kutatómun- 
kánk van, hogy hogyan is kell ezt meg nem történtté 
tenni. 


Elba Soft a termék... De most mit kellene tennünk? A telepítő 
script egy ügyes hibaüzenetet produkált: 


Server: Msg 911, Level 16, State 1, Line 1 

Could not locate entry in sysdatabases for 

$ database "Elba". No entry found with that name. 
3 Make sure that the name is entered correctly. 


Ilyenkor következik az adatbázis létre- 
hozása - kézzel. Az SOL Server eseté- 
ben általában minden művelet végre- 
hajtására kétféle módszer áll rendelke- 
zése. Az egyik a grafikus mód, az Enter- 
prise Manager segítségével. A másik a 


sa nem két, hanem huszonkét lépésből alkalmazások megfelelő SOL-parancs kiadása a 
áll. E nélkül is van munka elég! Ouery Analyzerrel. Nézzük meg először 
tulajdonosaira? a grafikus módszert! 


Adatbázis létrehozása 
Tegyük fel, hogy megvásároltuk az Elba 
Soft által fejlesztett csodálatos SOL-ala- 
pú ügyviteli rendszert. A fejlesztő érti a dolgát, tehát egy A4- 
es papírlapon kapjuk meg a kiszolgálóoldali telepítés lépéseit 
(ezt hívják integrált telepítésnek, a papír is bele van integrál- 
va). Ezt elolvasva kitűnik, hogy a telepit.sal fájlt kell lefuttat- 
nunk, és ez létrehozza a táblákat, sőt, alapadatokkal is feltöl- 
ti azokat. Igen ám, de hogyan? 
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Az Enterprise Managerben ássunk le a 
szerverig, jelöljük ki, majd keressük 
meg az eszközsoron a varázspálca 
ikont. Jó hírem van a rendszergazdák számára: gyakorlatilag 
minden értelmes feladatra van varázsló! 
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Select Wizard ME xi 


Please select the Wizard you wish to use: 


"Sala 
E Database 
Create Database Wizard 
Create Index wizard 
Create Login Wizard 
Create Stored Procedure Wizard 
Create View wizard 
Full-T ext Indexing Wizard 
Data Transformation Services 
DTS Export Wizard 
DTS Import Wizard 
E Management 
Backup Wizard 
Copy Database Wizard 
Create Alert Wizard 
Create Job Wizard 
Database Maintenance Plan wizard 
Index Tuning Wizard 
Make Master Server Wizard 
Make Target Server Wizard 
Web Assistant wizard 


am. Ranlicztian 














SOL-varázslók az Enterprise Managerben 


Válasszuk ki a , Create Database Wizardot", és indítsuk el! A 
második képernyőn adhatjuk meg a létrehozandó adatbázis 
nevét (Elba) - és másra nincs is talán szükségünk. A finnyá- 
sabbak külön partícióra tehetik az adatbázis- és a naplófájlt, 
de mi most Next-Next-Next-Finish módszertan szerint dol- 
gozzunk. (Mit lehetett volna még megadni? A fájlok nevét, 
méretét és növekedési paramétereit. ) 

Ha magyar SBS-sel van dolgunk, az új adatbázis automatiku- 
san magyar nyelvi beállításokkal születik (ékezetérzékeny, 
kis-nagybetű-érzéketlen). 

Ugyanez Transact SOL-utasítással: 


CREATE DATABASE ELBA 


Ha angol SBS-t használunk, az adatbázis is ilyen nyelvű lesz, 
viszont szerencsére utólag ezt át lehet állítani magyarra: 


ALTER DATABASE ELBA COLLATE Hungarian CI AS 


(Megjegyzem: ez esetben a varázsló nélküli adatbázis-létre- 
hozás jobb lett volna, mert egy lépésben meg lehetett volna 
adni a nyelvi opciókat.) 

Ez után már sikeres lehet az sal kiterjesztésű fájl lefuttatása. 





Felhasználók létrehozá 





beengedése adatbázisokba 

A következő lépés az lesz, hogy - akár le van írva az A4-es 
lapon, akár nincs - felhasználókat kell létrehozni az SOL Ser- 
veren, és el kell látni őket a megfelelő jogosultsággal. (Előfor- 
dulhat, hogy a telepítőseript ezt is megcsinálja, de ha nem, 
íme a kézi módszer.) 

Mielőtt nekiesnénk a feladatnak, röviden meg kell ismerked- 
nünk az SOL Server jogosultsági modelljével. Két tényezőt 
kell figyelembe venni: 





m Az SOL Server teljesen különválasztja a felhasználó 
azonosítását (autentikáció) a jogosultság megszerzé- 
sétől (autorizáció). Az első lépés csupán azonosítja a 
felhasználót (tudni fogjuk, hogy ő biztosan Fontos Gyu- 
la), de ezzel még jogosultsághoz nem jut. Tehát 
mindössze az előszobáig jut, nem ugorhat fejest az 
ágyba. 

m Az SOL Server kétféle autentikációs eljárást tartalmaz: 
önmaga is képes a nevek és jelszavak ellenőrzésére 
(SOL Authentication), vagy kész tényként elfogadhatja 
a Windows által elvégzett felhasználóazonosítás ered- 
ményét (Windows Authentication). Ez utóbbi esetben 
nem kell újra begépelnünk jelszavunkat, hanem ripsz- 
ropsz beléphetünk az SOL Serverbe. 

Telepítés után mindössze a Windows autentikáció van bekap- 
csolva, ezért erre tekintettel kell lennünk a felhasználók létre- 
hozásánál: felesleges SOL-felhasználókat létrehozni, mert 
úgysem jelentkezhetnek be mindaddig, amíg az SOL Server- 
en nem engedélyezzük az SOL -autentikációt (nem fogjuk en- 
gedélyezni). Mi marad ebben az esetben? Nem kell felhasz- 
nálókat létrehozni, csupán a meglévő Windows-fiókokat 
(vagy csoportokat) kell ,beengednünk" az adatbázis-kezelő- 
be (az előszobába). Tegyük fel, hogy Fontos Gyulát kell been- 
gednünk. Az Enterprise Managerrel nyissuk ki a bal oldali fá- 
ban a Security ágat, majd kattintsunk a Logins elemre. 

A jobb oldalon mindössze két , felhasználó" árválkodik, ame- 
lyek közül az egyik nem is felhasználó, hanem Windows-cso- 
port (BUILTINRRendszergazdák), a másikkal viszont (SA) nem 
lehet bejelentkezni, mert ez egy sima SOL-felhasználó, ami 
csak akkor használható, ha az SOL-autentikáció engedélyez- 
ve van (nincs). Amit itt látunk, azt jelenti, hogy aki tagja a Win- 
dows-féle Rendszergazdák csoportnak, az bejöhet az elő- 
szobába. Sőt, megnyitva ezt a sort, kiderülne, hogy ezek a fic- 
kók egyben az SOL Server teljhatalmú rendszergazdái is, mi- 
vel ehhez a csoporthoz hozzá van rendelve a System 
Administrators SOL-szerep. 
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Beépített felhasználók az SOL Serverben 


Máris látunk egy utat Gyula beengedésére: ha beledobjuk a 
Rendszergazdák Windows-csoportba, automatikusan SOL- 
adminná válik! Csak ezt ne! 

Engedjük be személyesen Gyulát az SOL Serverbe, és ad- 
junk neki jogot az Elba adatbázisra! Jobb klikk a Logins ágon, 
New Login... 
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General ] Server Roles ] Database Access ] 


d) vere 


Authentication 
6 Windows Authentication 





[FELATRAXVEGI yula 5 I 


Domain: 


FALATRAX r] 





6 Grant access 
C Deny access 


€ SOL Server áuthentication 


Specify the default language and database for this login. 


Password: 





Defaults 


Database: - 
Language: [ cDefaulb s 





Windows-felhasználó beengedése az SOL 
Serverbe 


A felső mező melletti gombbal válasszuk ki Gyulát, az auten- 
tikáció maradjon Windows (ahogy a keret mutatja), és ha még 
ebben a lépésben be szeretnénk engedni az Elba-adatbázis- 
ba, kattintsunk a Database Access fülön, és ott pipáljuk be, 
hogy hozzáférhet a megfelelő adatbázishoz. (A fenti ábrán 
látható Database mező, ahol szintén kiválasztottam az Elbát, 
nem ad jogosultságot!) 

Ezzel Gyula hozzáfér az Elba adatbázishoz, mégpedig olyan 
jogosultsággal, ami ott a Public csoportnak jár. Azaz semmivel. 
A jogosultságállítás (autorizáció) adatbázisonként külön-kü- 
lön történik. Nyissuk ki a baloldali fában az Elba adatbázis, 
kattintsunk a Users elemre. A jobb oldalon két felhasználó lát- 
ható: dbo és FGyula. Nyissuk meg Gyulát, és a teljesen 
egyértelmű felületen adjuk meg neki azokon a táblákon a jo- 
gosultságokat, amit az A4-es említ. 

Ugyanez Transact SOL-utasítással: 


EXEC sp grantlogin "FALATRAXWGyula" 

USE Elba 

EXEC sp grantlogin "FALATRAXWGyula" 

GRANT ALL on valamelyik tábla to [FALATRAXNFGyula] 


Természetesen a GRANT ALL helyett finomabb jogosultság- 
szabályozás is elképzelhető, hiszen a jogosultságokat műve- 
letenként állíthatjuk be (például GRANT SELECT..., DENY 
INSERT... stb.) 


helyreállítási 





ak beállítása 

SBS-környezetben nem szokás különösebb figyelmet fordíta- 
ni a mentési stratégiára. Sokan így gondolkodnak: ,ha min- 
dennap csinálunk egy teljes mentést, abból nem lehet baj!" 
Pedig mekkorát tévednek! 

A teljes mentés ugyanis nem szabadítja fel a tranzakciónap- 
ló inaktívvá vált részét (részletes magyarázat SOL-tanfolyam- 
on), így az gyűlik, gyűlik, gyűlik addig, amíg meg nem zabál- 
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ja a merevlemez teljes területét. Ha ez bekövetkezik, minden 
megáll. 

Két módszer áll rendelkezésünkre a tranzakciónapló daga- 
dásának megakadályozására: 

m Néha csináljunk tranzakciónapló mentést, akár értel- 
mesnek tekintjük ezt a lépést, akár nem. Ez ugyanis tör- 
li a napló inaktív részét. 

m Ha viszont nem mentjük a tranzakciónaplót, szóljunk az 
SOL Servernek, hogy ne őrizgesse a végtelenségig, 
hanem időnként törölje. 

Ez utóbbi módszert fogjuk most kipróbálni egérrel és script- 
tel. Nyissuk meg az adatbázis tulajdonságlapját (jobb klikk El- 
bán, tulajdonságok), menjünk az Options fülre, és állítsuk be 
a Recovery Mode mezőt Simple-re. 


EZTET ENEEETSETTETTTT 3 
General] Data Fies ] Transaction Log] Fiegroups Options ] Permissions [ 
Access 





TT Restrict access 





Recovey ———————,—,—————————  — —— — 
Modet Full . 

sam 
TT ANSI NULL default 


TT Recursiye tíggers 

[7 Auto update statistics 

[7 Tom page detection 

TT Allow cross-database ownership chaining 


TT Auto shrink 
[7 Auto create statistics 
I Use guoted identifiers 





Compatibüly — — 


Database compatibilty level 80 - 


Levet 





Simple Recovery beállítása az adatbázison 


Ugyanez Transact SOL-utasítással: 


sp dboption "Elba", "trunc. Log on chkpt.", true 
Ugye, milyen egyszerű volt? Bármelyikünk kitalálta volna, 
pusztán az opció nevéből (Simple) :-) 


Adatok publikálása a webre 

Ma már gyakori igény, hogy egy vállalat a termékeiről napra- 
kész információt jelenítsen meg a weblapján. Kisvállalatoknál 
ez az igény azzal egészül ki, hogy lehetőleg ingyen, és prog- 
ramozás nélkül oldjuk meg a feladatot. Erre teszünk most kí- 
sérletet a Web Assistant Wizard segítségével. 

Az eszközről annyit kell tudni, hogy statikus HTML-weblapo- 
kat generál ugyan, de többféle módon képes ezeket frissíte- 
ni. Ha a naprakészség a fontos — az adatok változását egy 
triggerrel figyelve — akár minden egyes adatmódosítás hatá- 
sára képes újragenerálni a lapot. Ha azonban a módosítások 
száma ezt a módszert már gazdaságtalanná teszi (például 
másodpercenként száz módosítás történik), időzített módon 
is képes ugyanerre. 

A legfontosabb tudnivaló azonban nem ez, hanem hogy ho- 
gyan képes az eszköz olyan weblapokat faragni, amelyek 
beilleszkednek a cég webhelyén kialakított sémába. Ennek 
az a titka, hogy a varázsló egy előre elkészített sablonba , bo- 
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rítja" az adatokat. Nincs más dolgunk, mint egy gyönyörű, 
céglogós-menüs sablon-lap megfelelő helyére beírni az 
c9einsert data here905 címkét, és a varázsló ide fogja be- 
szúrni az adatokat tartalmazó táblázatot. 

Ha magát a táblázatot, annak cellát, sorait is , díszíteni" sze- 
retnénk, tegyünk egy üres táblázatot a sablonba, és minden 
mezőjébe be kell írni az c9einsert data here965 kulcsszót. 
Az ismétlendő minta kezdetét (a sor elejét) c7ebeginde- 
tail9oz, a végén c9eenddetail90 jelzéssel adhatjuk meg. 
A varázsló innentől ki fogja találni a gondolatainkat. 

Most nézzük végig a varázsló által feltett kérdéseket! (Maga 
a Web Assistant Wizard az Enterprise Manager varázspálcás 
ikonja mögül csalogatható elő.) 

Elsőként meg kell adnunk a publikálandó adathalmazt, ami 
lehet egy egész tábla, egy tárolt eljárás vagy akár egy álta- 
lunk megfelelően megfogalmazott SELECT-utasítás ered- 
ményhalmaza. 





Web Assistant Wizard - (local) Mr. xi 


Start a New Web Assistant Job 
Specily a name for the Web Assistant job. then select the data to publish. 





What do you want to name this Web Assistant job? 


What data do you want to publish to the table on the Web page? 
(7 Data from the tables and columns that ! select 

€C Result setís) of a stored procedure ! select 

€ Data íromthe Transact:SOL statement ! specify 





Mi lesz a webes publikálás adatforrása? 
Tábla? Tárolt eljárás? Lekérdezés? 


Az egyszerűség kedvéért most legyen egy tábla, amiből a kö- 
vetkező lapon kiválaszthatjuk a megfelelő mezőket. Ez a mód- 
szeris lehetővé teszi egyébként meghatározott sorok kiválasz- 
tását, így általános esetben nincs szükség saját SOL-utasítás 
kifaragására. Miután ügyesen kiválasztottuk a kívánatos me- 
zőket, lássuk az , időzítési" beállításokat! Az idézőjel azért in- 
dokolt, mert az egyik beállítás (When the SOL Server data 
changes) valójában nem időzítést jelent, hanem ebben az 
esetben egy olyan trigger kerül a kiválasztott táblára, ami min- 
den sikeres tranzakció után újragenerálja a HTML-lapot. 
Triggerelt esetben ki kell még választanunk, hogy mely me- 
zők változását vegye figyelembe, egyébként a varázsló ké- 
sőbb azonos lapokkal folytatódik. 

Ha szeretnénk, hogy a kész weblap minden teketóriázás, ké- 
sőbbi bonyolult művelet nélkül azonnal megjelenjen a weben, 
változtassuk meg az alapértelmezett útvonalat, és mentsük in- 
kább a CNnetpubiwwwroot könyvtárba. Akár ez lehet a főlap, 
ha default.htm nevet adunk neki. Ha más nevet választunk, 
természetesen nekünk kell gondoskodnunk majd arról, hogy 
a céges főlapról egy linkkel el lehessen érni ezt a lapot is. 

A következő kérdés azt feszegeti, vajon a weblapot a varázs- 
lónak kell összetákolnia, vagy van egy sablonunk, benne a 
már említett c9einsert data here965 jelöléssel. Az egyszerű- 
ség kedvéért most az első eseten megyünk végig, a formá- 
zástis a varázslóra bízzuk. 


Web Assistant Wizard - (local) FEEL 


Schedule the Web Assistant Job 


te 6 


Optionally. specily the freguency for updating the data and generating the Web 





When should the Web Assistant update the Web page? 


ig 
C Ondemand. 
C Only one lime at 
Dztef20050203. -]  Timefr83515 — 


C whenthe SOL Server data changes. 
C Atregularty scheduled intervals. 


F Generate a web page when the vízard ís completed, 





(Mé ] 





Mikor készüljön el a weblap? időzítve? Trig- 
gerelve? 


Ekkor meg kell adnunk a weblap és a táblázat címét, valamint 
hogy tegyen-e a lapra dátumot, majd következik a formázás: 
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Format a Table 
Indicate column and border formatting and font characteristics. 


Do you want column names displayed in the HTML table? 
G es, display column names) 

€ No. display data only, 
What font characteristics do you want to apply to the table data? 


G Figed T Bold 
C Piroportional TT hatie 





[7 Drax border lines around the HTML table. 








A Web Assistant formázási lehetőségei 


Az egyszerűség gyönyörködtet. A következő lapon beállíthat- 
juk, hogy az összes sort látni szeretnénk-e, vagy csak az el- 
ső x darabot (gondoljuk végig, mekkora terhet jelent mind az 
SOL Server, mind a potenciális látogatók számára egy tízezer 
soros HTML-lap!), illetve hogy kérünk-e lapozást — mondjuk 
20 soronként. És ezzel végeztünk is. Az utolsó lapon még le- 
hetőségünk van sal fájlba menteni az egész Web Assistant 
Jobot, hátha később scripttel szeretnénk újabb lapokat gene- 
ráltatni. (Az sp. makewebtask tárolt eljárást kell meghívni egy 
jó tucat paraméterrel, a varázsló is ezt teszi egyébként.) 


Időzített mentések, index- 
karbantartás és hasonló feladatok 
(obok) készítése 

Még egy fontos feladatunk van, különböző karbantartási mű- 
veleteket kellene időnként futtatni. Az SOL Server adatbázisai 
meghálálják a törődést. A töredezettség-mentesítés és az in- 
dexek statisztikáinak frissítése érezhetően fürgébbé tehet egy 
ellustult adatbázist, a mentések pedig egyébként is létfontos- 
ságúak. 

Ezekre a tipikus feladatokra is van külön eszköz, a neve: Da- 
tabase Maintenance Plan Wizard. (Ott találjuk, ahol a többi 
varázslót.) Ha csak egyszerűen végighajtjuk Next-Next-Next- 


Finish-sel, pusztán egy időzített teljes mentést alakítunk ki, ér- 
demes figyelmesen végigolvasni és kiválasztani a további le- 
hetőségeket is. 

Elindítása után ki kell választanunk, melyik adatbázisokra ké- 
szítjük a karbantartási feladatot. (Természetesen az Elba 
adatbázisra.) 

Mindjárt a következő lap érdekes beállítási lehetőségekkel 
szolgál. Itt találjuk ugyanis a töredezettségmentesítést, csak 
éppen nem ez a neve, hanem , Reorganize data and index 
pages". Ez nemcsak átrendezi a rekordokat, hanem arra is 
képes, hogy a helyfoglalási egységként használt 8 kilobájtos 
úgynevezett lapokon (page) bizonyos százaléknyi üres helyet 
képez, hogy ha a sorrendnek megfelelő további rekordok jön- 
nek létre, azoknak legyen fenntartva hely, vagyis a töredezett- 
ség minél később következzen be ismét. A töredezettség- 
mentesítés , mellékhatása", hogy az újraépülő indexeknek fel- 
frissül a statisztikája is, így ha ezt kiválasztjuk, a második op- 
ció (, Update statistics. ..") beszürkül. 

De mire is jó az , Update statistics..." lehetőség? Abban se- 
gít, hogy az SOL Server minél pontosabban meg tudja hatá- 
rozni egy lekérdezésről előre, még annak konkrét lefuttatása 
előtt, hogy hány sort fog visszaadni. Ez lehetővé teszi, hogy 
mindig a megfelelő indexet választhassa ki a lekérdezés fel- 
gyorsítására. Ez a témakör messzire vezet, az SOL-guruk 
földjére, most elégedjünk meg ennyivel, és higgyük is el min- 
den további magyarázat nélkül, hogy ez igaz, így működik és 
szükség van rá. (Az SOL Cuery Optimizer mindig dinamiku- 
san, az adatok és a lekérdezés paramétereinek függvényé- 
ben választja ki a megfelelő indexeket és illesztési (join) stra- 
tégiát.) 

A harmadik opcióval a varázslat a töredezettségmentesítés 
hatására felszabaduló üres helyet adja vissza az operációs 
rendszernek, ha megkérjük rá. 

Alapértelmezésben ezek a feladatok minden vasárnap éjjel 1 
órakor hajtódnak végre. 


Database Maintenance Plan Wizard - (local) EA 2] 
Update Data Optimization Information 
As data and index pages fil, updaling reguires more time. Reorganize your data (ga 


and index pages to improve perforrnance. 


FF. Heorganize data and index pages 
€C Reorganize pages with the original amount of Íree space 





(7 Change Íree space pet page percentage to: fed 
FT Updete statistics used by guery optimízer, Sample rad 2 of the database 
7 Herjove unused space kom database fies 
when it grows beyond: Jó MB 
Armount of free space to remain after shrink: [0 - zzofthe data space 


Schedule: JOccurs every 1 week(s) on Sunday, at 1:00-00. 


eltesz 
mégse [sé 








Töredezettségmentesítés minden vasárnap 
éjjel egykor! 


Haladjunk tovább! A következő lapon az adatbázis integritá- 
sának (hibátlanságának) ellenőrzése kérhető. Mi az, ami el- 
romolhat? Elvileg semmi, és több éves tapasztalataink szerint 
is egyáltalán semmi, de ha mégis, akkor például a 8k-s lapok 
közötti láncolt lista sérülhet meg. Az ilyesmit a redundáns 
adatok segítségével javítani is tudja az SOL Server, hát ad- 
junk esély neki erre, pipa be! Ez a feladat alapértelmezésben 
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az előzőekben említett töredezettség-mentesítés előtt egy 
órával fog lefutni, tehát vasárnap éjfélkor, hogy már hibátlan 
rekordokat tologasson ide-oda a rendezgetés során. 

A következő lapon nem kell tennünk semmit, az egy teljes 
mentést fog beütemezni akkorra, amikor az előző folyamatok 
már remélhetőleg véget értek, tehát vasárnap éjjel 2-re. Egy 
Next után beállíthatjuk, hogy maximálisan hány mentést őriz- 
zen meg és haladhatunk tovább. 

A következő lap a tranzakciós napló mentéséé, pipáljuk be, 
és figyeljük meg, hogy ez - vasárnap kivételével — a hét min- 
den napján le fog futni, mégpedig ismét éjfélkor. Itt is be lehet 
állítani, hogy hány mentést őrizzen meg az utókor számára. 
Haladjunk tovább. 

Már csak a feladatok futásáról készített jelentést kell össze- 
kattintanunk (fájlba, MSDB-be, email címre lehet jelentést to- 
vábbítani) és készen is vagyunk. A Web Assistant Jobokkal 
ellentétben a Maintenance Plan utólag is könnyedén megvál- 
toztatható, mert ügyesen feltüntették az Enterprise Manager 
konzolfájában, itt: 


"fú SOL Server Enterprise Manager 
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A karbantartási varázslás eredménye 


Egyébként maguk a feladatok négy különböző tartalmú és 
ütemezésű SOL Agent jobban futnak, és az xp. salmaint kül- 
ső tárolt eljárást hívogatják ezernyi paraméterrel. 


Adatpumpa (export-import) 

különböző forrásokból, -ba 

Utolsóként a sorban még egy nagyon fontos feladat: adatok 
átvitele egyik adattárolóból a másikba. Ezt a munkát az SOL 
Server mellé csomagolt, azzal szorosan együttműködő, de 
mégiscsak önálló program, a Data Transformation Services 
(DTS) végzi. Onnan lehet tudni, hogy független eszközről van 
szó, hogy zokszó nélkül visz át adatot akárhonnan akárhová 
(mondjuk Paradoxból DB2-be) anélkül, hogy akár a forrás, 
akár a cél kötelezően SOL Server lenne. Nem finnyás: amihez 
van OLEDB provider, az jó neki. 

ADTS teljes körű kihasználása ismét nagyon messzire vezet, 
ugyanis egy adatfolyam-vezérelt igencsak alternatív progra- 
mozási eszközről van szó. De szerencsére az egyszerűbb ex- 
port-import feladatok végrehajtására itt is van — na mi? — va- 
rázsló! 

Válasszunk ki az Enterprise Managerben egy tetszőleges 
táblát, és suhintsunk oda neki a jobb egérgombbal! A gyors- 
menüben találjuk az Import Data. . . és Export Data. lehetősé- 
geket: 


a 
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Adatátvitel DTS-sel 


Terjedelmi korlátok miatt ezt az eléggé egyértelmű varázslót 
nem nézzük végig tételesen, csupán a végén lévő mentési 
lehetőséget emelném ki: itt derül ki, hogy egy DTS-csomag- 
ot hoztunk létre, amit nemcsak azonnal lefuttatni, időzíteni, 
hanem elmenteni is lehet, akár további módosítás, akár 
későbbi futtatás céljából. A csomag itt lesz fellelhető a ké- 
sőbbiekben: 
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E CI Meta Data Services 


A varázslóval készített DTS-csomag 


Érdemes megtekinteni a csomagot a DTS-szerkesztőben, 
hogy lássuk, a lehetőségeknek csupán 196-ánál járunk ebben 
a szép témakörben. 
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